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(54) A method and architecture for an interactive two-way cteta communication network 

(57) A two-way data communication device such as 
a data ready cellular telephone, a two-way pager, or a 
telephone communicates via a two-way data communi- 
cation network with a server computer on a computer 
networl^ that has an interface to the two-way data com- 
munication networK i e, is coupled to the two-way data 
communication network. For example, the computer 
network can be a corporate wide area networK a corpo- 
rate local area network, the Internet, or any combination 
of computer networks. The two-way data communica- 
tion device utilizes a client module to transmit message 
including a resource selector chosen by the user to a 
server on a server computer on the computer network. 
The server processes the message and transmits a 
response over the two-way data communication net- 
work to the client module. The client module interprets 
the response arKi presents the response to the user via 
a structured user interface. Alternatively, the user trans- 
mits a request that directs the server to transmit the 
response to the request to another location or to 
another user. 
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Description 

A portion of the disclosure of this patent document contains material, that includes, but is not limited to Appendix I, 
Appendix II. and Figures 10A to 10T, which is subject to copyright protection. The copyright owner has no objection to 
the facsimile reproduction by anyone of the patent document or the patent disclosure, as rt appears in the Patent and 
Trademark Office patent files or records, kxit otherwise reserves all copyright rights whatsoever. 

BACKGROUND OF THE INVENTION 

Field of the Invention 

This invention relates generally to c^ta communications, and in particular to two-way data communication devices 
Including a cellular telephone, a two-way pager, and a telephone that permit a user to Interface with and interact with a 
server on a computer network. 

Description of Related Art 

For at least the last five years, the wireless communication industry has tried to merge confuting with wireless 
communications. This industry wide effort has held the promise of bringing software intelligence to telecommunication 
devices Including mobile wireless communications devices such as cellular telephones and two-way pagers as well as 
standard telephones. 

After years of research and development, and hundreds of millions of dollars* Investment by some of the largest 
companies in the field such as Motorola. AT&T, Sony. Matsushita, Phillips and IBM. the results have been nothing but 
disappointing. Typically, the intelligent communication devices resulting from these efforts include txrth the hardware 
necessary for a computer module and the hardware for a wireless communications nx)dule. Exanples of such products 
are Sinnon from IBM and Bell South, MagicLink from Sony, and Envoy from Motorola. 

Fundamental design and cost problems arising directiy from the approach taken by the designers of these intelli- 
gent communication devices have limited widespread market acceptance of these devices. The combination of a wire- 
less communication module with a computing nrKxlule leads to a device that is too bulky, too expensive, and too 
inflexft^le to address the market requirements. 

The combination of the two modules is too large and too heavy to fit in a user's pocket. Pocket size Is a key require- 
ment of the mobile communication market which renr^ains unmet by these devices 

In addition, the cost of these devices is ctose to the sum of tiie cost of the computer nrrodule and of the communi- 
cations module, which is around a one thousand dollar end-user price. Market research Indicates that the market for 
intelligent wireless communications devices is at prices around $300. Even witii a 20% compound cost decline, it would 
take five years for the combination units to meet toda/s customers' price requirements. K Is tfierefore unlikely that 
devices designed by combining a computer and a wireless module, no matter how miniaturized and cost reduced, can 
satisfy the cost requirement of the market during this decade. 

To succeed in tiie market place, intelligent wireless communication devices must be at>le to sipport a wide variety 
of applications specific to each market segment. Typically, these applications must be added to the device by the end- 
user after purchase. Thus, the device must provide a method for loading the initial application and for sutjsequent 
updating of the application. 

The price sensitivity for intelligent communication devices and the size limrtalions means that an intelligent commu- 
nication device cannot support the amount of core menxjry (RAM), a hard disk or non-erasat}le memory, or a traditional 
floppy disk drive, commonly found on computers. These limitations close the traditional routes for delivering new appn- 
cations or updates to intelligent communications devices. 

As a result, the current crop of intelligertt communication devices run only the few applications which were burned 
into their ROMs at the factory or which are contained in a ROM card plugged into a slot designed for this purpose. This 
scheme lacks the flexibility needed to run the thousands of applications required to address the fragmented require- 
ments of the market arxJ provides no simple method for updating the applications after the device has been sold. 

Two other communication oriented attempts at bringing intelligence to telephones are Short Messaging Service 
(SMS) and Analog Display Service Interface (ADSI). SMS specifies how messages are delivered to and from a ceOular 
telephone and how the cellular telephone shoufcJ store the messages. SMS also defines some sinple processing which 
the cellular telephone can perform on the message, such as calling a telephone number enrt)edded in the message. 

SMS's architecture is similar to that of paging networks with the difference that devices implementing the SMS 
architecture operate over the control channel of the cellular telephone network. SMS is deployed primarily in Europe 
over the GSM network 

SMS messages are not delivered in real time. The time delays can range from 30 seconds i^a to 10 minutes, which 
makes SMS unsuitable for real time applk^ations. The main purpose of SMS is tiie delivery of messages. SMS does not 
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spedfy an application protocol or cellular telephone application module which further restricts its usefulness in running 
applications on cellular telephones. After a few years of deployment in Europe, SMS implementations have been limited 
to notification services such as two-way paging and voice mail notification. 

SMS as a medium ts unsuited to building applications which allows the retrieval, manipulation, and storage of infor- 

5 mation. This is the reason why the industry giants have not turned to SMS in their quest to add intelligence to cellular 
telephones, but have cons^tently attempted to conrdsine a conrtputer module with a wireless communications module. 

ADS1 was designed as an extension to Interactive Voice Response Systems. ADS I allows a smart telephone with 
a small screen to display prompts to assist users in choosing among various options. By using visual prompts instead 
of cumbersome voice prompts, ADSI is thought to make the use of interactive voice services easier and faster. 

10 ADSI allows data to be sent from the service provider to the telephone in the form of screens. ADSI also allows the 
telephone to respofKi through touch tone signaling with a special coding to describe the full alphanumeric character set. 
With ADSI, a telephone is primarily a passive device. Services send text screens to the telephone, and the telephone 
sends back short strings indicating the choices the user made from Uie text screen. 

ADSI makes no provisions for performance of processing in the telephone. As a result, ADSI generates a high traf- 

15 fic load on the telephone network since each user input is sent back to the service for processing. This makes ADSI 
unsuitable for wireless networks where t>andwidth is at a premium and *air efficiency" is one of the most sought after 
qualities. The lack of processing capability in the telephone and the high bandwidth requirements of ADSI have pre- 
vented it from being considered by the industry for implementing intelligent vinreless devices. 

Up to now, intelligent communication devices have combined a computing module with a wireless communications 

20 module. However, to gain widespread acceptance, a two-way data communication device with processing capability 
arKi the ability to run a wide variety of differing user applications is needed. In addition, such a device should be com- 
parable in size, cost and weight to a cellular telephone. 

SUMMARY OF THE INVENTION 

25 

According to the principles of this invention, the prior art limitations of combining a computer module with a wireless 
communication module have been overcome. In particular, a two-way data communication device of this invention, such 
as a cellular telephone, two-way pager, or telephone includes a client module that communicates with a server compu- 
ter over a two-way data comnuinication network. The principles of this invention can be used with a wide variety of two- 

30 way data communication networks. For example, two-way data communication networks for cellular telephones that 
may be used include a cellular digital packet data network as well as TDM A. CDMA, and GSM circuit switched data net- 
works; and the AMPS analog cellular network with a modem. Similarly, for two-way pagers, two-way data communica- 
tion networks include PACT, the new AT&T endorsed two way paging standard, or other priority two-way paging 
networks with data transport capability. The two-way data communication network for a telephone is the public switched 

35 telephone network. 

Using the two-way communication device that includes the client module, a user can provide information to the 
sender computer, retrieve information from the server computer, provide data to an application on the server computer 
which uses the data arKi provides information to the two-way communication device, or sends the information to another 
location. The functionally provided to the user of the two-way communication device is limited only by the applications 

40 available on a server computer that is accessible to the user over the two-way data communication network 

This invention allows for the first time two-way communications devices such as cellular telephones, two-way pag- 
ers, and telephones to become open application platforn^ which in turn empowers software developers to deliver 
value-added applications and services to any two-way comnrtunication device that incorporates the principles of this 
invention. This is a radical shift from the current situation where telephones and two-way pagers are closed, proprietary 

45 systems. Consequently, an even playing field is created for the market to irrvent new uses for two-way communication 
devices and for two^ay communication networks. Any entity from corporations to individuals can make new applica- 
tions available to the installed base of two-way data communication devices that include this invention without physical 
modification or addition to the two-way comnuinication device. Years after purchase, a two-way communication device 
incorporating tiiis invention will run all the applications which were developed since its purchase. 

so Further, all these applications are available without the end user having to add anything or make any modification 
to the two-way communication device. Also, the applications are independent of the two-v^y data communication net- 
work The applications do not depend on any feature of the two-way data communication network Thus, the applica- 
tions are unaffected by a change in the two-way data communication network. 

Also, the applications on the server computer are independent of the two-way data communication device with 

55 which the server computer Is interacting. An application on the server computer can communicate with any two-way 
data communication device tfiat includes the client module of this invention and a network interlace module to transmit 
data over, and receive data from the two-way data communication network These two features mean that an invest- 
ment in developing an application is insulated from either advances in two-way data communication devices, or 
advances in two-way data communication network technology 
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As indicated above, the two-way data communication device of this invention utilizes a client nxxlule to transmit a 
message including a resource locator selected by the i^er over the two-way data communication network to a server 
on a server computer on the computer network. For example, the computer network can be a corporate wide area net- 
worK a corporate local area network, the Internet, or any combination of computer networks. 

5 The server processes the message, i.e. executes the application addressed by the resource locator and transmits 

a response over the two-way data communication network to the two-way data communication device, which stores the 
response in a memory. The client nxxlule interprets the response and generates a user interface using information in 
the response. In one embodiment, the user interface includes at least one user data input option that is associated with 
a resource locator. In another embodiment, the user interface is a display. 

10 The resource locator associated with the at least one user data input option can address any one of a wide variety 
of objects. In one entxxliment. the resource locator associated with the at least one user data input option addresses 
an object on the server conputer that transmitted the response. In another entKxJiment, the resource locator 
addresses an object on another server computer coupled to the two^ay data communication network. In yet another 
enrtbodiment the resource locator addresses an object stored in the two-way comnrwnication device. 

15 When the user selects the at least one user data input option, the client nrnxJule interprets the selection and if 
required, appends any input data to the resource allocator associated with the at least one user data Input option. The 
client module transmits a message including the resource bcator with any apperxJed input data to the server computer. 
Alternatively, the resource locator with any appended data can be addressed to another server computer, or can 
address an object stored In the two-way communication device. If the resource locator addresses an object on a server 

20 computer, the client nxxJule provides the message to the network interface module which in turn transmits the message 
over the two-way data communication network. 

Thus, in this embodiment, the message originally transmitted to the two-way data communication device included 
all the information necessary for the client module to generate the user interface, to associate the user selection and 
any data entered with a particular resource locator, and to transmit the appropriate resource locator in a subsequent 

25 message. The client module includes an interpreter that processed the information in the message. Since the message 
included all the information needed by the client module, the server computer that transmitted the message retained no 
state information concerning the message. Consequently, the server conputer Is def ir>ed as a stateless server compu- 
ter. 

An important aspect of this invention is that the message includes all information necessary for the client nxxlule 

30 to generate the user interface and a particular user interface can be independent from other user interfaces. Unlike prior 
art systems that gave the user a predetermined menu from which to select items, or limited the teer to an E-mail like 
format, according to the principles of this invention, the user interfaces and possible interactions available to the user 
are determined only by the applications that developers make available. The possible interactions and user interfaces 
for one application can be totally different and Independent from the possiWe interactions and user Interfaces of another 

35 application. Thus, a cellular telephone, two-way pager, and a telephone all truly become an open platform. 

These features of the invention are a significant departure from prior art systems. Typically, in the prior art use of 
a particular application on a particular platform required that the application be compatible with the operating system 
on that platform. Further, each time a new version of the application was released, the user was required to take steps 
to update the appUcation on the users platform. Further, if the user of the platform did not nxxlify the operating system 

40 as new versions of the operating system were released, at some point In time, the platform would no longer be capable 
of processing a new version of an applicatton that required a current version of the operating system. 

This invention eliminates these prot)lems. As explained above, the client nxxJule in the two-way data communica- 
tion device functions an interpreter. The application on the server conputer provides all information necessary for the 
Interpreter to generate a user interface on the two-way data communication device, and in response to user selections 

45 or data input ising the user interface, to route messages to an appropriate server, i.e. either the server that sent the 
original information or another server. 

Thus, the dient nxxlule only interprets this information and interacts appropriately with the hardware of the two-way 
data communication device Consequentiy, to update an application requires only changes on the server computer and 
not char>ges in each two-way data communication device that communicates with that server computer. This invention 

so eliminates the usual requirement for distribution of application software, and application software updates to the erxl 
user of the two-way data communication device. 

In one embodiment, a two-way cteta communication system for communication between a server computer and a 
two-way data communication device sheeted from a group consisting of a cellular telephone, a two-way pager, and a 
telephone. Includes a two-way data communication network, a server computer coupled to the two-way data communi- 

55 cation network and a two-way data comnruxnication device coupled to the two-way data communication network. The 
server computer includes a two-way data conmiunication interface module coupled to the two-way data communication 
networK arxJ a server coupled to tiie two-way data communication interface module. The server receives a message 
including a resource locator from the two-way data communication network. The resource locator includes an address 
of the server computer and of an application on that server computer. The server processes the message using the 
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resource locator. In this embodiment, the server transmits a response to the message over the two-way data commu- 
nication network 

The two-way data communication device, selected from the group correisting of a cellular telephone, a two-way 
pager, and a telephone, includes a network interface nrodule coupled to the two-way data communication network, and 
£ a client module coupled to the network interface module. The client module transmitted the message including the 
resource locator to the server over the two-way data communication network. The client module also processes the 
response to the message from the server. The response includes information for a user interaction over the two-way 
data communication network. 

The client module of this invention is lightweight, and thus requires only lightweight resources In a two-way data 
10 communication device. Consequently, the client module can use existing resources in such a device and therefore does 
not add to the cost of the two-way data communication device. 

In one embodiment, the interpreter within the client module includes a plurality of managers including a user inter- 
face manager coupled to a display of the two-way data communication device where the user interface manager han- 
dles interactions with the display. The user interface manage- also Is coupled to a keypad of the two-way data 
75 communication device and handle interactions with the keypad. Herein, a keypad can be a telephone keypad, the keys 
found on a two-way pager, or other data input interface of a two-way communication device. 

In one embodiment, the response generated by the server computer includes a plurality of resource locators and 
at least one of the plurality of resource locators includes an address to another server coupled to the communication 
network. 

20 According to the principles of this invention, a method for using a two-way data communication device, selected 
from a group consisting of a cellular telephone, a two-way pager, and a telephone, to communicate with a server com- 
puter includes: 



25 



generating a message by a client module in 
response to data entered by the user of a two-way 
data cortimunication device coupled to a two-way 
data conununication network, 
30 wherein the client module executes on a 

microcontroller of the two-way data 
communication device; and 

the message includes a resource locator; 

transmitting the message over the 
two-way data cotmminication network to a 
server computer wherein the server 
computer is identified by the resource 
locator; 

executing an application on the server 
computer identified by the resource locator to 
generate a response to the message; and 

transmitting the response to a location 
identified by the application. 
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As indicated above the location can be the two^ay communication device, another server computer, or some other 
device coupled to the server computer. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates one emt>odiment of the airnet network of this Invention that indudes the two-way data commu- 
nication devices of this invention. 
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Figures 2A to 2H are illustrations of a series of screen displays of the two-way data communication device of this 
invention that illustrate one application of the principles of this invention. 

Rgures 3A to 3F are illustrations of a series of screen displays of the two-way data communication device of this 
invention that illustrate a second application of the principles of this invention. 
5 Rgures 4A to 41 are illustrations of a series of screen displays of the two-way data communication device of thfe 

invention that illustrate yet another application of the principles of this invention. 

Rgure 5 illustrate another embodiment of the airnet network of this invention that includes the two-way data com- 
munication devices of this invention and an airnet network translator. 

Rgure 6 is a block diagram of a mobile wireless comnxinication device that includes the client and support modules 
10 of this invention. 

Rgure 7 is a more detailed diagram of the nK>bile wireless communication device and a server computer within the 
airnet network architecture of this invention. 

Rgures 8A to 8D are a process flow diagram showing the process performed by the client in the mobile wireless 
communication device and the server on the server computer of Rgure 7. 
15 Rgure 9 is a diagram of a mobile wireless communication device of this invention that includes a novel predictive 
text entry system that is a part of this invention. 

Rgures 10A to 10T are one embodiment of a letter frequency table. 

Rgure 11 is a process flow diagram for one embodiment of a data entry process that includes the novel predictive 
data entry process of this invention. 
20 Rgure 1 2 is a more detailed diagram of the mobile wireless communication device and the airnet network translator 
within the airnet network architecture of the another embodiment of this is invention. 

Rgure 13 is a process flow diagram showing the various processes performed by the airnet network translator of 
Figure 12. 

Rgure 14 is a diagram illustrating the various module managers included in one embodiment of the client module 
25 of this invention. 

Herein, objects with the same reference numeral are the same object Also, the first number of a reference numeral 
indicates the Rgure where the object first appeared. 

DETAILED DESCRIPTION 

30 

According to the principles of this invention, a novel airnet network 150. i.e., a two-way data communication net- 
worK interconnects any one. any combination, or all of two-way data communication devices 100, 101, or 102, that 
each include this invention, with a wide variety of computer networks 120, 130. and 140. lor example. As explained 
more completely below, each two-way data communication device 1 00. 1 01 . and 1 02 can be configured to transmit data 

35 to and receive data from any desired con*ination of computers on computer networks 120, 130. and 140. Airnet net- 
work 150 is the two-way data communication path from the two-way data communication device to the particular com- 
puter that is accessed by the user of that two-way data communication device. 

Each wireless communication device 100 that includes this invention can communicate over airnet network 150 
with any server computer 121, 131. and 141 on airnet network 150 that includes at least one application that commu- 

40 nicates and interacts with the processes of this invention that are included within device 100. Thus, device 100 can 
access information on the computer network and provide information to the computer network. Similarly, a two-way 
pager 101 , and a telephone 102 with a modem 103, that each include this invention, can communicate over airnet net- 
work 150 with any of server computers 121 , 131 , and 141 that includes at least one application that comrrxinicates and 
interacts with the processes o1 this invention that are included within devices 101 and 102. 

45 As explained more completely below, an application on a server computer can be accessed by any two-way data 
communication device that can comrrujnicate with that server conputer. The application is independent of the particular 
type of two-way data communication device that Is used to access the application and independent of the particular two- 
way data communication network used. This means tiiat a user can access an application from arrywhere so long as 
the user has a two-way data communication device that can communicate with the server computer. 

so In one embodiment, a process on wireless communication device 100 is configured as a client process and the 
applications on server computers 121, 131 and 141 on airn^ network 150. tiiat communicate with the client process, 
are server processes. This architecture allows some of the processing Ixjrden to be moved away from cellular tele- 
phone 100. across airnet network 150, to a server module on any computer on airnet network 150. 

Specifically, a wireless communication device 100 e.g.. a cellular telephone, with a telephone like keypad, commu- 

55 nicates via a data capable cellular telephone network 1 10. e.g.. a cellular digital packet data telephone network, wrth an 
application on a server computer on a computer network tiiat has an int^ce to data capable cellular telephone net- 
work 1 10. For example, the computer network can be a corporate wide area network 120, a corporate local area net- 
work 130, or pertiaps the Internet 140. 

Similarly, a two-way pager 101 communicate via a two-way pager network 111 with an application on a server 
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computer on a computer network that has an interface to two-way pager network 111. Again, for exanple, the computer 
network can be a corporate wide area network 120, a corporate local area network 130. or perhaps the Internet 140. 
Finally, a telephone 102 communicates via a modem 103 and public switched telephone network 1 12 with an applica- 
tion on a server computer on a conriputer network that has an interface to public switched telephone network 1 12. As 

5 with the other two-way data communication devices, the computer network can be, for example, a corporate wide area 
network 120, a corporate local area network 130. or perhaps the internet 140. 

In each of two-way data communication devices 1 00, 101 , and 1 02, the client process is stored as a client module 
In the device and the execution of the client module on a microcontroller in the device is sometimes referred to as the 
client process. The client process performs important processing functions locally. This allows the communication 

10 between the client process, hereinafter sometimes referred to as simply client, and the server process, hereinafter 
sometimes referred to as server, to be minimized and the server computing requirements to grow slowly as the number 
of clients, i.e., users, grows. 

The client module is small, e.g., under 64 KByte, and requires only low processing power congruent with the mem- 
ory chips and built-in nnicrocontrollers in two-way data communication devices such as cellular telephone 100. two-way 
15 pager 1 01 . and telephone 1 02. Thus, unlike the prior art attempts at an intelligent telephone, the cost, size, and battery 
life of either cellular telephones, two-way pagers, or telephones that incorporate this invention are not adversely 
affected. 

While client/server architectures have been used extensively in computer networks, a client/server architecture 
implemented using two-way communication data devices such as cellular telephone 100. two-way pager 101, or tele- 

20 phone 102 yields new arxi unexpected results. This invention allows for the first time a wide variety of two-way data 
communication devices irKluding but not linrdted to cellular telephones, two-way pagers, and telephones to become 
open application platforms which in turn empowers software developers to deliver value added applications and serv- 
ices to any two-way data communication device which incorporates the principles of this invention. 

This is a radical shift from the current situation where cellular tdephones. two-way pagers. arKl telephones are 

25 closed, proprietary systems. Consequently, an even playing field is created for the market to invent new uses for cellular 
telephones arKi data capable cellular networks, for two-way pagers and two-way pager networks, and for telephones on 
the public switched network. 

Any entity from corporations to individuals can make new applications available to the installed base of data ready 
cellular telephones, two-way pagers, and telephones, that include this invention without physical modification or addi- 

30 tion to the devices. Years after purchase, a two-way data communication device with this invention can run all the appli- 
cations which were developed since Its purchase. Further, all these applications are available without the user having 
to add anytiiing or make any modification to the two-way data communication device. These features of the invention 
are a significant departure from prior art systen^. Typically, in the prior art, use of a particular application on a particular 
platform required that the application be compatible with the operating system on that platform. Further, each time a 

35 new version of the application was released, the user was required to take steps to update the application on the user's 
platform. Further, If the user of the platform did not modify the operating system as new versions of the operating sys- 
tem were released, at some point In time, the platform would no longer be capable of processing a new version of an 
application that required a current version of the operating system. 

Also, small devices, such as cellular telephones or pagers, usually do not have card slots, floppy or hard disk drives. 

40 or other mear^ commonly found on computers to add or update applications. This limitation has led prior art attempts 
at intelligent communication devices to design closed systems with fixed functionality. Such devices can neither adapt 
nor be adapted to the fast changing requirements of the market place and so have not met with market success. 

This Invention eliminates these problems. The client process in the two-way data communication device functions 
an interpreter. The application on the server computer provkdes all information necessary for the Interpreter to generate 

45 a user interface on the two-way data communication device, and in response to user selections or data input using the 
user interface, to route messages to an appropriate server, i.e. either the server that sent the original information or 
another server. 

Thus, tiie client process only interprets this information and interacts appropriately with the hardware of the two- 
way data communication device. Consequentiy, to update an application requires only changes on the server computer 
so and not changes in each two-way data communication device that communicates with that server computer. Th^ Inven- 
tion eliminates the usual requirement for distribution of application software, and application software update to the 
end user of the two-way data communication device. 

For example. If Initially, two-way pager 101 receives a response to a message from an application on server com- 
puter 121 on corporate wide area network 120, the interpreter In two-way pager 101 generates a user interface on dis- 
ss play screen 106 using information In tiie message. As described more completely below, options presented in the user 
interlace can allow the user to access information, or provkie Information to any one, any combination of, or all of net- 
works 120, 130, and 140. 

Specifically. In the response to the message from two-way pager 101 . the application Initially accessed on server 
computer 121 included resource locators for applications on eachof networks 120, 130. 140, typically common gateway 
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interface programs, accessible to the user of pager 101 as well as irrformation required to generate the user interface. 
Consequently, when the user makes a particular selection or enters data, the interpreter accesses the appropriate 
resource locator arxl appends any necessary data to the resource locator The client transmits a message including the 
resource locator to the appropriate server. 

5 As shown by this exanple, the applications on networks 120, 130, 140 send to the two-way data communication 

device all information necessary to generate a user interface, eirKl to process all user input. Consequently, only an appli- 
cation must be changed to update the information provided to the two-way data communication device. 

In addition, since all the information needed by the client to generate a user interface and all information necessary 
for the client process to respond to any input data is included in the message, the computer server does not retain any 

w state information concerning the information transmitted to the client process. Consequently, the computer server is 
stateless. 

Each two-way data communication device 1 00. 1 01 , and 1 02 that utilizes airnet network 1 50. includes a data com- 
munication capability, a display screen, preferably a multi-line display screen, and storage capability for tiie processes 
of this invention in an on-tx)ard memory, and for the message being processed. Nearly every data capable cellular tel- 

15 ephone, e.g., a telephone that utilizes a cellular digital packet data networK includes excess on-board memory capacity 
arxJ a multi-line display screen. These hardware resources are often available, but unused in a data capable cellular tel- 
ephone because of the indivisibility of memory chip packages. The inclusion of tfie proc^es of tiiis invention in such 
cellular telephones tiierefore has very little effect on the cost. size, and power consumption of the cellular telephone. 
Similarly, the inclusion of the processes of this invention in two-way pagers and telephones, that indude a microcontrol- 

20 ler and memory, has very little affect on the cost. size, and power consumption of these devices. 

Thus, unlike prior art approaches that attempted to combine a computer module and a wireless communication 
module in a single package, this embodiment of the invention preferably utilizes the memory and processing power that 
currently exists in the cellular telephone 1 00. two-way pager 1 01 , telephone 1 02 or other wireless or landline two-way 
data communication devices. This approach limits the cost of the resulting device and overcomes many of the problems 

25 of ttie prior art devices, e.g.. tiie size and weight of the two-way data communication device is not changed, and. as 
explained above, updating user applications is removed from cellular telephone 1 00. two-way pager 101, and telephone 
102. 

In particular, unlike devices produced by previous industry attempts at combining computing modules and a wire- 
less cellular nxxjule, two-way data communication devices which incorporate this invention are size and cost conrpeti- 

30 tive with voice-only telephones and can, for the first time, satisfy tfie market cost and size requirements for an intelligent 
cellular telephone, for example. 

The incremental cost of supporting interactive applications on cellular telephone 100, two-way pager 101 , and tel- 
ephone 102 is reduced to at most a slightiy larger screen ttiat is required to display the application to the user. This is 
a fraction of the cost of adding a complete computer module to a cellular telephone, for example. 

35 The incremental power consumption required to support this invention is also very small, as the incremental mem- 
ory and screen required are small consumers of power compared to tiie cellular radio itself. Intelligent two-way data 
communication devices built according to the principles of this invention are not expected to have a signif icantiy lower 
battery life than standard celliJar telephones, or two-way pagers, for example. 

The configuration and processes of the client process in two-way data convnunication devices 100. 101. arxl 102 

40 are similar when the differences in the devices and the two-way data communication network over which the devices 
communicate are considered. Consequentiy, in the following description, the operation of data-ready cellular telephone 
1 00 is considered. The same or similar operations can be performed on two-way data communication devices 101. and 
102. The main difference is that some device deperxlent features within the client module must be changed to accom- 
modate the particular hardware used in the two-way communication device. However, the client module architecture 

45 described more completely below limits the number of changes that must be made 

As indicated above, in response to user actions, wireless communication device 1 00 transmits a message, typically 
a data request, to a server computer 121 on computer network 120 and receives a response to the message. Alterna- 
tively, tiie user action can result in directions to server computer 1 21 on computer network 1 20 to transmit the response 
to the message to another location or to another user. Also, wireless communication device 100 can receive a message 

50 from any one of the computers coupled to airnet network 1 50. 

An important aspect of this invention is that the client module interpreter in wireless corrvnunication device 100 
generates a user interface by which tiie user can lx)th initiate arxl receive messages from a variety of applications. The 
interactions take f>lace in real-time and are not limited by the client module interpreter. The uses of wireless communi- 
cation device 100 are limited only by the availability of applications on server computers. 

55 The applications available are determined l>y application developers. Prior to considering one implementation of 
the invention in further detail, several illustrative examples of applications that can be implemented according to the 
principles of this invention are described. These applications are iilusti-ative only and are not intended to limit the inven- 
tion to ttie particular applications and features described. 

In one use, the user configures cellular telephone 100 to access server computer 121 on XYZ corporate wide area 
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network 120. In response to the access by the user, server computer 121 transmits a card deck to cellular telephone 
100 over data capable cellular telephone network 1 10. As explained more completely below, a card deck includes one 
or more cards, and each card is interpreted by the client module to gen&ate a user interface screen. 

In the embodiment illustrated in Figure 2A. the initial card deck transmitted to cellular telephone 100 includes an 

5 introductory display card and a choice card. Figure 2A is an example of introductory screen display 200 that is gener- 
ated on display screen 105 by the client process in cellular tel^hone 100 by interpreting the display card. As used 
herein, a display screen is the physical display apparatus in a two-way communication device. A screen display is the 
image presented on the display screen. 

In this enrtKxliment. display screen 105 is a pixel di^lay that di^lays graphics. In another embodiment, display 

10 screen 105 displays only text and so the graphics would not appear on display screen 105. Screen display 200. and 
other screei displays described more completely below, include a horizontal arrow, i.e.. a multi-card deck indicator, to 
communicate to the user that the current deck includes another card. The inclusion of screen indicators, such as the 
multi-card deck indicator, to communicate with the user is optional. The functionality of this invention is independent of 
such screen indicators. 

75 When the user presses a predetermined key. or key sequence, the client process in cellular telephone 100 inter- 
prets the next card in the card decK i.e.. the choice card, and in tum generates a menu 201 (Fig. 2B) of items that can 
be accessed by the user. In this embodiment, each of the menu items is available on server computer 121 to the user 
who. in this example, is a representative of XYZ corporation visiting ABC Designs. 

As explained more completely below, each of the menu items is associated with a resource locator that includes an 

20 address of the particular object associated with that menu item, typically an address to a common gateway interface 
program on server conrtputer 121. In general, a resource locator includes an address and may include apperKled data. 
The address can be to a local object within the two-way data communication device or to a remote object on a server 
computer. As is known to those skilled in the art. the common gateway interface is an Internet standard that is used to 
dynamically generate information, e.g., cards. In view of this disclosure, other techniques to generate dynamic cards 

25 could be used. 

Initially the highlighting of the first line of menu 201 is not present. When a key on the keypad of cellular telephone 
1 00 is pressed, the menu item corresponding to that key is highlighted on screen 105. Thus, menu 201 shows the f irst 
item highlighted to indicate that the one key was pressed by the user. However, highlighting a selected hem is a feature 
that is specific to this example, and in general is not required to implement the inventioa Other methods can be used 
30 to indicate the iter's choice on display screen 105 such as an .an^ow pointing at the choice, tf such an indication is 
desired. 

After the one key is pressed, the user presses a predetermined key. eg., an enter key. to verify the selection. Alter- 
natively, in another embodiment, the verification of the selection is not required. In both embodiments, the resource 
locator for the selection is transmitted to server computer 121 by the client process in cellular telephone 100 over data 

35 capable cellular telephone network 110. In response to the selection, server computer 121 processes the message 
corrtaining the selection, and in this embodiment, transmits another card deck to cellular telephone 100. 

The client process in cellular telephone 1 00 interprets the first card in the deck received from server computer 121, 
which is a choice card, and generates a screen display 202, that includes a second menu as illustrated in Fig. 20, on 
display screen 1 05. Initially, none of the iten^ in the second menu are highlighted. 

40 Notice that screen display 202 includes a header, that describes the selection made by the user on screen display 
201 . in addition to the second menu of choices available to the user. A nuilti -display screen card indicator 203, e.g.. in 
this emtxxiiment. a hand icon with a finger pointing down, shows that the screen associated with the current choice card 
includes additional items that are not shown on display screen 105. Herein, a screen can be larger than the number of 
lines available on display screen 105 and so the user must scroll the screen display to view the complete screen. 

45 Thus, to view the additional items, the user presses a first screen scroll key, e.g.. a next key. on cellular telephone 
100. In this embodiment, when the first screen scroll key is pressed, each line of the display is rolled up one line. The 
resulting display has an icon with a finger pointing up (not shown) if the menu requires only two screen displays. If the 
menu requires more than two screen displays, the second screen display of the menu would have two icons, one with 
a finger pointing up, and another with a finger pointing down. To scroll between the various lines in the second menu, 

so the user uses the first screen scroll key, and a second screen scroll key. 

If the user displays the last line of a card, e.g., the last line in the second menu, and presses the first screen scroll 
key nothing happens. In this embodiment, the user must make a choice before the next card is availat>le. 

Screen display 202 also includes representations of two soft keys, a home key 204, and an info key 205. In this 
example, these soft keys are defined only for the card used to generate screen display 202. When the user presses a 

55 predetermined key sequence, the home key is highlighted to indicate the selection. In this embodiment, when the home 
key is selected, the user is returned to screen display 200. In another emtxxjiment, the user could be returned, for 
example, to a home screen display that is displayed each time the user activates cellular telephone 1 00 for use on airnet 
network 150. 

The home key is associated witii a pointer, tinat in one entbodiment Is a resource locator, and the card addressed 
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by the pointer is displayed by the client process when the home key is selected by the user. Specifically, if the pointer is 
to a card in the cun-ent deck, the client process simply displays that card. If the pointer is to other than a card in the 
current deck, the client process in cellular telephone 100 retrieves the deck containing the card at the location kientif ied 
by the pointer. The location coukJ be. for example, either a memory in cellular telephone 100, or a memory in computer 
5 121. 

Similarly, when the user presses another predetermined key sequence, the info key is highlighted to indicate the 
selection. In this embodiment, when the info key is selected, a help screen is displayed for the user that describes the 
possible selectior^. The particular contents of the help saeen are determined by the provider of the service. Specifi- 
cally, a pointer is associated with the info key and when the info key is depressed by the user, the information stored at 
10 the location identified by the pointer is retrieved and interpreted by the client process in cellular telephone 100. 

Returning to the menu in Figure 2C, since the user wants to determine the status of an order, the user pushes the 
two key on the keypad of cellular telephone 1 00. In response to the key press, the second choice in the menu is high- 
lighted as shown In Figure 2C. In response to verification of the key press, e.g., the user presses a predetermined key 
sequence, cellular telephone 100 transmits a check open order request to computer 121 . i.e, the client process trans- 
15 mits a message that includes a resource locator associated with the menu item selected by pressing the two key 

In response to the check open order request, computer 121 transmits yet another card deck to cellular telephone 
1 00. The client process in cellular telephone 1 00 interprets this decK that is an entry card, and in turn generates a pur- 
chase order number entry screen display 206 (Fig. 2D) on display screen 105. Notice that screen display 206 has a pre- 
vious soft key 207 and a fax soft key 208. Again, each of these soft keys has an associated pointer and the information 
20 Stored at the location identified by the pointer is retrieved and interpreted by the client process when the user selects 
the soft key. 

In this example, the user does not select a soft key, but rather the user enters the purchase order number as shown 
in Figure 2E using the keypad of cellular telephone 100. The user enters only the various nun4)ers. The client process 
formats the number and inserts the dashes as shown in Figure 2E. 

25 After the purchase order is entered, the user p>resses a predetermined key sequence to indicate to the client proc- 
ess that entry of the purchase order numt>er is complete. Notice that the user is entering data and not simply selecting 
a menu item. The i^er is utilizing cellular telephone 1 00 as if cellular telephone 1 00 was a computer connected to net- 
work 120. but. as explained more completely below, cellular telephone 100 is similar to a standard digital data capable 
cellular telephone that communicates over data capable cellular telephone network 1 1 0. Specifically, cellular telephone 

30 1 00 is not a combination of a computer module arxl a wireless communication module as in prior art attempts to create 
an irrtelligent telephone. 

In addition, the user enters data using only the standard cellular telephone keypad. Thus, cellular telephone 100 
eliminates tiie need for a computer keyboard or for a sophisticated touch screen tiiat recognizes rrxrtion of a pointing 
ol5|ect- This is important to maintaining tiie size, weight, and power requirements of cellular telephone 100 similar to 

35 those of a voice-only cellular telephone. In one entxxdiment. to facilitate data entry, as explained more completely 
below, cellular telephone 100 includes a text prediction process that reduces the number of key strokes required to 
enter text data. In this embodiment, the text prediction process is turned on or off for each enti-y card. 

In response to entry of the purchase order number, the client process transmits a request to server computer 121 
for the particular purchase order. Specifically, the client process appends tiie entered data to a resource locator and 

40 transmits a message containing the resource locator to server computer 121. Server computer 121 . in response to the 
message, retrieves tiie appropriate purchase order and transmits tiie purchase order as a card deck to the client proc- 
ess in cellular telephone 100 over airnet network 150. 

The client process Interprets the card deck and generates a screen display 209 (Fig. 2F). Initially, fax key 208 is not 
highlighted in screen display 209. 

45 Notice that screen display 209 includes multi-display screen card indicator 203 to show the user that the purchase 
order screen contains more information that can be displayed at one time on display screen 105. 

After the user reviews the purchase order, the user presses tiie key sequence for fax key 208 and in response, fax 
key 208 is highlighted as illustrated in Rgure 2F. 

In response to selection of fax key 208, the client process retrieves the card deck at the location klentified by the 

so pointer associated with fax key 208. If the location is on server computer 121 , the client process transmits a message 
including a resource locator to server computer 121 and in response to tiie message, server computer 121 transmits 
back yet another card deck If the location is on a server computer other than server computer 1 21 . the client proc^ 
transmits a message including a resource kx:ator to that server computer arxl in response to the message, that server 
computer transmits back yet anotiier card deck If the location identified by ttie pointer is witiiin cellular telephone 100, 

55 the client process simply retrieves tiie deck In eittier case, fex form 210 (Rg. 2G). ttiat is an entry card, is displayed on 
display screen 105 by cellular telephone 100. This example denrx)nstrates the information accessed by the client proc- 
ess can be located in any number of kxations. The resource tocator associated witti the fax key identifies the appropri- 
ate location. 

\Nhen fax form 210 is displayed, the user enters the facsimile machine telephone number at ABC Deigns, as 
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shown in Figure 2H. using the cellular telephone keypad. In this embodiment, the telephone number is automatically 
formatted by the client process. After the telephone number is entered, the client process appends the telephone 
number to a resource locator and transmits the information to server computer 121 . 

When server computer 121 receives the information, server computer 121 executes a common gateway interface 

5 application (CX3I) pointed to by the resource locator. The CGI application grabs the necessary information and transmits 
the information via e-mail to a fax gateway The fax gateway upon receipt of the e-mail, converts the information to a 
fax and sends the informatbn to the specified telephone number. Thus, cellular telephone 1 00 requires neither a printer 
connection nor a print driver, but yet can print using the facsimile machine at ABC Designs. 

As illustrated in this exanpte, cellular telephone 100 trananitted a request for a particular purchase order, and 

10 scheduled transmission of data responsive to the request to a local machine capable of printing the data. Thus, the 
processes of this invention, as descrit^ed more completely below, in cellular telephone 100 in combination with data 
capat>le cellular telephone network 110 and server computer 121 permit cellular telephone 100 to effectively utilize an 
application on server computer 121 on network 120 even though cellular telephone 100 utilizes only a microcontroller 
found in tel^hone 100 and does not required a separate computer module as in the prior art 

15 In addition, the client process using the information transmitted from server computer 121 , i.e. the cards, generates 
a wide-variety of user interfaces as illu^rated in Figures 2A to 2H. The particular configuration of the various user inter- 
faces is defined by the cards transmitted in a card deck Consequently, the user interface is not fixed to one particular 
format such as an E-mail type format, but rather the format is variable and can be redefined by each card that is inter- 
preted by the client process. Also, in general, the user interface for one application on a server computer is independent 

20 from the user interface for another application on that server computer. 

Specifically, the application accessed on server computer 121 generates the card deck and so in turn defines each 
of the various user interfaces. Each user interface permits the user to identify a particular selection. Each particular 
selection could result in generation of a different user interface with different selections. Thus, the user internees are 
limited only by the applications accessible to the two-way data communication device. 

25 As shown below, a wide variety of applications can be provided on a server computer. Despite the robustness of 
the client module in interpreting a wide variety of application, typically, the client process is lightweight and thus requires 
only lightweight resources, e.g.. 60 Kbytes of readK>nly memory (ROM) for the client module, 10 Kbytes of random 
access memory (RAM), and less than one million instructions per second (MIPS) of processing power. Since the client 
process neecte only these lightweight resources in a two-way data communication device, the client can use existing 

30 resources in such a device and therefore does not add to the cost of the two-way data communication device such as 
data capable cellular telephone 100. 

In another embodiment, the user can configure cellular telephone 100. to access server computer 131 on corporate 
local area network 1 30. In response to the access by the user, computer 1 31 transmits a home card (not shown) to cel- 
lular telephone 100 which in turn generates a home saeen display on display screen 105. 

35 When the user selects personal information on the home saeen display or on a subsequent screen display asso- 
ciated with the home card, a message Including a resource locator for a personal information deck is transmitted from 
cellular telephone 100 to computer 131 . In response to the message, computer 131 transmits a card deck that includes 
a display card arKi a choice card to cellular telephone 100. In these examples, the card deck is described as including 
one of three cards, a display card, a choice card, and an entry card. However, these examples are illustrative only and 

40 are not Intended to limit the invention to those particular emtxxliments of cards. In view of this disclosure, those skilled 
In the art will be atHe to form combinations of these types of cards and define other types of cards, if such cards are 
appropriate for the particular application. 

The client process in cellular telephone 100 interprets the display card that includes image and text data and gen- 
erates screen display 300 on display screen 105 (Fig. 3 A). Screen display 300 includes a home key 301 . and an info 

45 key 302. When the user selects hon^ key 301 . the user is returned to the home screen. Info key 302 functior^ in a man- 
ner similar to that described above for info key 205. 

When the user presses a predetermined key, the client process interprets the choice card and a second screen dis- 
play 304 (Fig. 3B) is driven on display screen 105. Screen display 304 is a menu of the personal information that is 
stored on server computer 131 for use by the user of cellular telephone 100. Multi-display screen card indicator 203. 

so e.g., the hand with a finger pointing down, illustrates to the user that the list has additional items that appear on the next 
screen display Screen display 304 also indicates the number of E-mail messages, faxes, and voice messages waiting 
for the user. 

The user scrolls the screen display line by line until screen display 305 Is on display screen 105. Initially, the fourth 
item in the menu Is not highlighted. In this example, the i^er presses the four key on the keypad of cellular telephone 
55 100 to view the user's schedule. In response to the key press, the dient module In cellular telephone 100 transmits a 
message, including a resource locator associated with the menu item selected by pressing the four key, to server com- 
puter 131 using data capable cellular telephone network 1 10 and corporate local area network 130. 

In response to the message, server computer 131 executes the application identified In the resource locator. Upon 
completion of the execution, server computer 131 transnrtits, over corporate local area network 130 and data capable 
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cellular telephone network 110 to cellular telephone 100. a card deck that includes a choice card that describes the 
user's schedule for that day. 

In this embodiment, when server conrputer 131 completes the transmission, server computer 131 has completed 
the response to the message and has transmitted all necessary information to cellular telephone 1 00. Therefore, server 
5 computer 131 does not retain any state information concerning the transmitted information and so is referred to as a 
stateless server conrputer 131. In tiiis embodiment, the client process can only request a card deck. However, as dem- 
onstrated herein, card decks and the two-way Interactive data communication system of tiiis invention provide tiie user 
with a new level of capat^ility. 

When cellular telephone 100 receives the card decK tiie client process In cellular telephone 100 interprets the 
10 choice card and drives screen display 306 (Rg. 3D) on di^lay screen 105. Initially, the first item in the menu of screen 
display 306 is not highlighted. When the user depresses the one key on the keypad of cellular telephone 100. cellular 
telephone 100 highlights the first Item in the menu. Cellular telephone 100 generates screen display 308 (Fig. 3E) upon 
the user subsequently depressing a predetennined key. Screen display 308 includes a schedule key 309. tiiat when 
selected returns the user to screen display 306 (Fig. 3D). Screen display 308 also includes a more detailed description 
15 of tiie 10:00 a.m. meeting. 

White screen display 308 is active, if the user depresses a predetermined key. the user is presented with the 
options in screen display 310 (Rg. 3F). Initially, item two in screen display 310 is not higNighted. 

In this example, the user depresses key two on the keypad of cellular telephone 1 00 and so cellular telephone 100 
sends a message including a resource locator to server computer 131 to send an E-mail message to Bill Smitii confirm- 
20 ing the meeting at 10:00 a.m. When server computer 131 executes the application addressed by the r^ource locator, 
an E-mail message is sent. 

In another example, the user of cellular telephone 100 connects to Internet service provider computer 141 on Inter- 
net 1 40 using data capable cellular telephone network 110. Upon connection of cellular telephone 1 00. service provider 
141 transmits to cellular telephone 100 a card deck to generate Rgures 4A to 4C. 
25 The client process in cellular telephone 1 00 interprets the first card in the card deck from corrputer 141 and gen- 
erates screen display 400 (Fig. 4A). When tiie user presses a predetermined key, cellular telephone 100 displays 
screen display 401 (Rg. 4B), Screen display 401 provides the user with a series of choices tiiat group services alpha- 
betically. 

When tiie user depresses the seven key on the keypad of cellular telephone 1 00. cellular telephone 1 00 displays a 
30 list of the services that have letters P. R, or S as the first letter in the sen^ice name. In this embodiment screen displays 
401 and 402 are a single card, e.g.. a single screen. Each of the various services associated with a key has an index 
and when a particular choice is made by the user, the choice defines an index. The client process then displays all of 
the services with the index that con-esponds to the index defined by tiie user's choice. 

In screen display 402. the user is given a series of choices of services that are availat^le to tiie user under tab 
35 seven. Initially, item three in screen display 402 is not highlighted. In this exanrple. tiie user depresses the three key on 
the keypad of cellular telephone 100 to select tiie stock quotes and item three in screen display 402 is highlighted. 

In response to this selection, cellular telephone 1 00 transmits a request for a stock quote, i.e. a message including 
a resource locator, over cellular telephone network 100 and internet 140 to service provider 141. In response to tiie 
request, service provider computer 141 executes the application addressed by tiie resource locator The application 
40 retrieves a card deck tiiat, in turn is transmitted to cellular telephone 1 00. The card deck Includes a display card and an 
entry card. 

Upon receiving the card decK the client process in cellular telephone 1 00 interprets the display card and generates 
screen display 403 (Rg. 4D). When the user depresses a predetermined key. entry screen display 406 (Fig. 4E) Is gen- 
erated on display screen 105 of cellular telephone 100. 

45 Initially, the box with letters SUNW in screen display 406 is ernpty. The letters SUNW are entered in the box by tiie 
user to indicate the ticker symbol of the stock for which the user wants information. After the user has entered the stock 
ticker symbol, the user presses the predetermined key to indicate that the entry Is complete. 

In response to the entry by the user, the dient module appends the stock ticker symbol to the resource locator and 
trar^mits the resource locator to service provider computer 141 which, in turn, executes an application addressed by 

so the resource locator to retrieve the latest stock market information for the stock ticker symbol. Service provider 1 41 uses 
the retiieved information to generate a card deck tiiat contains the information and then transmits tiie card deck to cel- 
lular telephone 100. 

The dient process in cellular telephone 100 interprets the first card in the deck and generates screen display 409 
(Rg. 4F). For convenience, the Rgures 4F to 41 are grouped togettier and separated by a dotted line. However, at any 
K given time, in this embodiment, cfisplay screen 105 can display any four adjacent lines and so the grotping of lines in 
Figures 4F to 41 is for convenience only to demonstrate the level of information tiiat can be retrieved and displayed by 
the client process. The use of a four line display screen is illustrative only. The client process of this invention can work 
with any size display screen, even a one line display screen. However, a multi-line display saeen is prefen-ed. 

In tiie Rgures discussed above, the display screen is a pixel di^lay and so can display images. In anotiier embod- 
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iment, the display screen only displays text and is snnaller in size. For such an anbodiment. the various entries are 
abbreviated and only text Is displayed, but the general operation is iderrtical to that just described. Also, the various 
computer networks can be interlinked so that a user with access to one computer network can obtain information on 
another computer network. Moreover, the embodiments described above are merely illustrative. One important aspect 
of this invention is that cellular telephone 100 can interact with any type of server application that Is configured to com- 
municate with and interact with the client process in cellular telephone 100. Thus, the user is no longer limited to only 
a few services offered by a telephone network provider. 

In Rgure 1 . the cellular telephone user must address, i.e.. connect to. each computer of interest to access the dif- 
ferent services. Consequently, each computer requires the information necessary to communicate with cellular tele- 
phone 100. In another entixxjiment. not illustrated, cellular telephone 100 contacts a single central computer over data 
capable cellular telephone network 1 10. This computer is connected to each of the other networks illustrated in Figure 
1 . Consequently, the user of cellular telephone 100 sends a message Including a resource locator to the central com- 
puter, the central connputer processes the message and retrieves the Information addressed by the resource locator 
from the appropriate network shown in Figure 1 . After the requested irrformation is retrieved, the central conputer gen- 
erates a card deck and transmits the card deck to cellular telephone 1 00. In this embodiment, only one computer must 
be configured to communicate with cellular telephone 100. However, that same computer must be configured to com- 
municate with all other computer networks that are of interest to the user of cellular telephone 100. 

Hence, according to the principles of this invention, the client process on a two-wvay data communication device can 
initiate an interaction with a particular server computer. The server computer transmits (i) irrformation to the client proc- 
ess to generate a user interface, and (ii) a resource locator for each possible selection by the user from the user inter- 
face. The resource locators can address applications on the server computer, applications on over server computers, 
or an application on the server computer that in turn accesses other server computers. Consequently, the user of a two- 
way data communication device is limited only by the applications provided on the server computers. 

Further, the user can be provided new and/or updated capabilities by modifying the applications on the server com- 
puters. There is no requirement that the client process be changed for a new or updated application. The client process 
must only interpret the information received from an application and transmit a message for additional information. 
These operations are unaffected by a new or updated application. Consequently, as noted above, this invention does 
not require distribution of application updates or new applications to the end user of the two-way data communication 
device. 

Figure 5 is an illustration of another embodiment of airnet network 150. In this emfcxxJimerrt, the messages from a 
two-way data communication device, e.g., devices 100. 101. and 102 are directed to an airnet network translator 500. 
Airnet network translator 500 arxl a particular two-way data communication device. e.g.. any one of devices 100. 101 . 
arKi 102 communicate using the protocol for point-to-point communication on the particular network linking airnet net- 
work translator 500 and that two-way data communication device. For example, if data capable cellular telephone net- 
work 1 10 Is a cellular digital packet data network, either the transmission control protocol (TCP) or the user datagram 
protocol (UDP) can be used. 

Airnet network translator. 500 transfers data between the two-way data communication device and the selected 
computer network after trar^lator 500 validates the communication path, as explained more completely below, and 
encrypts the message transferred to the computer network H necessary. In addition, airnet network translator 500 col- 
lects transaction and billing information concerning the communication between the two-way data communication 
device and the designated computer network. Specifically, airnet network translator 500 provides access corrtrol for 
paying services and a logging mechanism for billing. Airnet network translator 500 can also provide a directory service 
to users. 

Figure 6 is a block diagram of a typical GSM digptal cellular telephone. Each of the hardware components in cellular 
telephone 600 is known to those skilled in the art and so the hardware components are not deso-ibed in detail herein. 
The compiled and linked processes of this invention are stored in ROM 601 as a client module 602 and support mod- 
ules 603. Upon activation of a predetermined key sequence utilizing the keypad, physical layer processor 610. that is 
sometimes referred to herein as a microcontroller, initiates a client process using client module 602 in ROM 601 . 

In this embodiment, client module 602 includes a plurality of manager modules, as explained more completely 
below. The particular manager modules utilized is determined by the characteristics of the particular cellular telephone 
1 00 in which client module 602 is Implemented. Client module 602 must include manager modules to interface with 
modules that control the particular hardware in cellular telephone 1 00, a manager module to interface with the particular 
cellular telephone network protocol used.by cellular telephone 100, and a manager module to interpret the card decks 
received. Therefore, the particular manager modules desaibed herein are only illi^ative of the principles of the inven- 
tion and are not intended to limit the invention to the specific modules descrS^ed more completely t^elow. 

In this embodiment, the client process controls the operations of a plurality of cellular telephone dependent support 
processes that are stored in ROM 601 such as a display module, a keypad module, and a network and terminal control 
module, that were referred to above collectively as support modules 603. The combination of the client process, display 
process, keypad process, and network and terminal control process are cor^dered foreground tasks by the microker- 
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nel in cellular telephone 600. Also, herein module and process are used interchangeably, but those skilled in the art will 
appreciate that the module is the computer software as stored in a menrwry. preferably, a ROM, of cellular telephone 
600 and the con-^ponding process is the execution of the module by the microcontroller in cellular telephone 600. 
Again, note that this invention does not require a separate processor and instead can utilize the processing power that 
5 already exists In cellular telephone 600. because as described above, the client process of this invention is so light- 
weight. 

The user interface for cellular telephone 600 determines the version of the user interface manager module that is 
stored in ROM 601 . In one embodiment, the parameters used to define the user interlace level are the display resolu- 
tion, the pixel access of the display, and the support of soft keys. One definition of the user interface levels is given in 
10 Table 1. 



TABLE 1 



15 


USER INTERFACE LEVEL DEFINITIONS 


Level 1 


Text only; 1 or more lines; 12 to 15 characters per line; and no soft keys. 




Level 2 


Text only; 4 or more lines; 20 to 25 characters per line; and soft keys. 




Level 3 


Pixel access; 1 50 by 75 pixels or larger; and soft keys. 



20 



The user interface manager module presents data to the display module which in turn drives display screen 605; 
and captures data entered by the user on display screen 605. In response to this information, the client process pre- 
pares a message for transmission by a network manager module. 

25 To more completely explain the operations performed over airnet network 1 50. Figure 7 is a block diagram that illus- 
trates the various components in one embodiment of this invention of cellular telephone 700. Those skilled in the art will 
appreciate that cellular telephone 700 includes circuitry and software similar to that illustrated in cellular telephone 600 
for voice and data operations supported by cellular telephone 700 in addition to the modules for operation on airnet net- 
work 750. Similarly, server conputer 743 includes other software and hardware that is known to those skilled in the art 

30 and so is not illustrated in Figure 7 for darity. 

In this embodiment, client module 702 in digital cellular telephone 700, that is executing on the microcontroller of 
telephone 7(X). communicates with server computer 743 over cellular digital packet data (CDPD) network 710. Cellular 
digital packet data network 710 is used to illustrate one embodiment of this invention on one two^ay data communica- 
tion network. The principles of this invention can be used with a wide variety of two-way data communication networks. 

35 For example other two-way data communication networi© for cellular telephones that may be used include TDMA, 
CDMA, and GSM circuit switched data networks; and the AMPS analog cellular network with a modem. Similarly, for 
two-way pagers, two-way data communication networks include PACT, or other priority two-way paging networks with 
data transport capability. 

Prior to considering the operation of this configuration of airnet network 750 in more detail, another aspect of this 
40 Invention is required. Specifically, a technique is required for conveying instructions from digital cellular telephone 700 
to a server application on server computer 743. and conversely. 

A telephone interaction description language (PIDL) is defined for use by service developers. A terminal Interaction 
language (TIL) is a distillation of the telephone interaction description language and describes the same interaction to 
digital cellular telephone 700 as the telephone interaction description language describes to computer 743. 
45 \A/ith the exceptions descrtoed more completely below, a process in the terminal interaction language is a com- 
pressed version of the same process written in the telephone interaction description language. The terminal interaction 
language allows easy parsing on the two^ay data communication device, which in turn makes the client smaller than 
a client for the telephone interaction description language that is readable by humans, but is not optimized for parsing 
by a machine. 

so The compression from the telepfione interaction description language to the terminal interaction description lan- 
guage is done typically at run time because some cards are conrputed cards and so cannot be precompiled. A wide 
variety of techniques can be used to convert the telephone interaction description language to terminal irrteraction lan- 
guage. The importarrt aspect s that, if bandwidth across the cellular telephone network Is limited, a compressed form 
of the telephone interaction description language is used. 

55 Preferably, each data type is compressed to facilitate optimal transfer over the two-way data communication net- 
work. For example, the vert>s in the telephone interaction description language are compressed using a binary tokeni- 
zation. Graphics are conrpressed using run length limited compression and text is compressed using any one of the 
well-known tediraques for text compression. While compression of the telephone interaction description language is 
not required to implement this invention, compression makes the invention nrore efficient by utilizing the bandwidth of 
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the network more effectively. 

Instructions in the telephone interaction deso-iption language and in the terminal interaction language are grouped 

into a deck and a card. Each deck indudes one or more cards. A card includes the inlornnation. i.e., a set of telephone 

interaction description language, required to generate a screen. As indicated atK>ve. a screen can be larger than the 
5 nunnber of lines in a display screen. Other equivalent terms for a card include a page and an atomic interaction. Thus. 

a card deck is simply a group of screens. The number of cards in a card deck is selected to facilitate efficient use of the 

resources in the two-way data communication device and in the aimet network 

For simplicity, in this embodiment, each card is a single operation. Herein, an operation is defined as a related set 

of actions such that the user does not encounter an unanticipated delay in moving from one action to the next. i.e. tiie 
70 user does not have to wait for client module 702 to retrieve another card deck from computer 743. Also, a deck may 

include definitions of soft keys that stay in force while the deck is active. I.e. being executed by the cellular telephone 

microcontroller. 

Computer 743 may contain stored static telephone imeraction description language decks. Conrputer 743 also gen- 
erates telephone interaction description language decks in resporree to data from, or choices made by. the user of cel- 
15 lular telephone 700. 

In the embodiment shown in Rgure 7, computer 743 converts a telephone interaction description language deck to 
a terminal interaction language deck, that in turn is transmitted to cellular telephone 700. The terminal interaction lan- 
guage is designed so that decks can be stored unaltered in memory 716 of cellular telephone 700 and referenced 
directly with little or no parsing. While telephone interaction description language decks on conputer 743 may contain 

20 references to images, a terminal irrteraction language deck contains the images at the end of the deck. Thus, if a par- 
ticular two-way data communication device does not support display of images, the images are easily stripped from the 
terminal interaction language deck before the deck is transmitted to that particular two-way data communication device. 

As indicated above, each interaction with the user of cellular telephone 700 is described by a deck or a series of 
decks, l-ogically, the user retrieves a terminal interaction tenguage deck stored in a memory 716 of cellular telephone 

25 700 after receipt from computer 743 over CDPD network 710. The user reviews the information displayed by cards in 
the deck and makes choices and/or enters requested information and then requests another deck as described atxsve 
with respect to Figures 2A to 2H. for example. 

When the user receives a deck, the first card of information is displayed on display screen 705. Typically, as shown 
above, the first card is text, an image, or a combination of an image and text. After the user has reviewed the first card. 

30 the user hits a NEXT key to view the next card in the deck. Similarly, a user can return to a previous card in the deck by 
using a PREV key. Thus, using the NEXT and PREV k^s, the i^er can navigate back and forth through the deck. 
Within a card, the user uses a scroll key or keys to move the portion of the card di^ayed up and down. This description 
of a particular method used to navigate through a deck and within a card is not intended to limit the Invention to this 
particular method. In view of this disclosure, those skilled in the art will be able to use a wide variety of ways to navigate 

35 through a deck and within a card. 

Cards, in this embodiment, are one of three types, a display card, a choice card, and an entry card. Independent 
of the type of card, the card can contain text and images. In addition, the invention Is not limited to these three particular 
types of cards. The definition of the three particular types of cards is used to facilitate a description of the invention and 
to assist the developer's In organizing applications. 

40 A display card gives Information to the user to read. The display content can Include any one of. or any combination 
of text, an image, arxf a soft key. The soft key is in effect only while the display card Is active. 

A choice card displays a list of choices for the user. The choices are auton^tically presented in a format specified 
on the choice card. See Appendix I, which Is a part of the present disclosure and is incorporated herein by reference in 
its entirety. As explained cibove. the user makes a choice by depressing the key corresponding to the choice. 

45 An entry card is used to obtain input data from the user. An entry card displays one or more entry lines. Typically, 
each errtry line includes a display followed by an entry line. The entry line, in this embodiment, can be for either numeric 
or text data. 

In this embodiment, choice and entry cards prevent the user from nrraving to the next card until the user has entered 
the requested information. When the user reaches the last card in a deck and hits the NEXT key, a request for a new 

so deck is initiated. The deck requested is determined by either the deck that the user has completed, or by the choices 
made by the user Also, when the deck is completed, the choices and/or data entered by the user typically are transmit- 
ted along with the request for the new deck to computer 743. 

Appendix I is one embodiment of a syntax for the telephone interaction description language and the terminal inter- 
action language of this invention, tn one embodiment, the telephone interaction description language is described using 

55 a subset of the standard generalized markup language. Only a sut>set of the standard generalized markup language is 
utilized so tiiat tel^hone interaction description language parsers also can be written easily using sinrple tools like lex 
and yacc. 

Returning to operation over airnet network 750, cellular telephone 700 Includes a display module 712. a keyboard 
module 71 1 , a client module 702, and a UDP interface module 714. In this embodiment, module 702 is stored in a non- 
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volatile memory (not shown) of telephone 700 and is executed by the microcontroller (not shown) in telephone 700. 
Modules 711, 712, and 714 operate under the control of client nxxJule 702. 

Client module 702 includes instructions that direct the microcontroller in cellular telephone 700 to perform the oper- 
ations described more completely below with respect to Figures 8A to 8D. The operations include sending uniform 

5 resource locator (URL) requests to HyperTexl Transfer Protocol (HTTP) server 749. parsing and displaying a TIL deck 
or decks returned by HTTP server 749, and generating new URLs based on the user*s key presses. For a description 
of HTTP server software and platforms that can run the HTTP server software, see, for exanrple. Ian S. Graham. The 
HTML Sourcebook. John Wiley & Sons. Inc.. New YorK Chapt. 8, (1995). which Is incorporated herein by reference. 
User datagram protocol (UDP) interface nrxxjule 714 couples CDPD network 710 to client module 702. and allows 

10 client module 702 to communicate using UDP over CDPD network 710. The user datagram protocol is well known to 
those skilled in the art and Is documented extensively UDP interface module 714 supports transmission of sirtple 
stand-alone messages between the connection partners. 

Display nrKXluIe 712 is a display driver that couples client module 702 to display screen 705 and so allows cliertt 
module 702 to specify the Information presented on display screen 705. The user interface manager module within cli- 

15 ent module 702 converts the display information in a card to instructions for display OKxJule 704 which in turn provides 
signals that drive the hardware that controls the operation of display screen 705. For example, if the TIL deck includes 
an image, the user interface manager module determines whether the active card calls for display of the image. If the 
active card directs the user interface manager module to display the image, the user interface manager module passes 
the image in memory 716 to display module 712. which in turn displays the image on display screen 705. 

20 Keyboard module 705 couples keypad 71 5 to client module 702. and stores data representing keys pressed by the 
user on physical keypad 715 in memory 716. Keylx>ard module 705 notifies client nrodule 702 when the user has 
pressed a key. 

When client module 702 is notified of a key press, the user Interface manager nxxJule within client nrodule 702 
passes information about the key press to display module 71 2 that in turn displays the appropriate character on display 

25 screen 705, if an entry card Is active. If the user interface manager module determines that a choice card is active, and 
the key press oorrespords to one of the choices, the user interface manager module sends instructions to display nrnxl- 
ule 712 that result in the choice being identified for the user. e.g.. highlighted as described above. 

In addition to HTTP server 749. host computer 743 includes a UDP interfece nxxlule 748. CGI programs 761 stored 
in a memory 755 of host computer 743. and TIL decks 760 stored in memory 755. 

30 HTTP server 749 uses UDP interface module 748 to send data to and receive data from CDPD network 710. TIL 
decks 760 are TIL decks that can be accessed by HTTP server 749. Static files containing PIDL decks are converted 
to TIL decks only once on HTTP server 749. CGI programs 761 are common gateway interface progranrre that produce 
PIDL decks that are used by HTTP sender 749 to produce TIL decks that in turn are transmitted via UDP interface mod- 
ules 748 and 714 and cellular telephone network 710 to client module 702. In this emlxxliment. the services available 

35 over airnet network 750 are applications accessible by HTTP server 749 on Internet 140 for which a service developer 
has written a PIDL deck or a CGI script that in turn generates a PIDL decK and Is stored on computer 743. 

The architecture in Figure 7 demonstrates some important aspects of this invention. First, the applications, the 
PIDL decks and CGI scripts in this embodiment, are independent of the particular two-way data communication net- 
work. For HTTP server 749 to communicate over a different two-way data communication network that does not support 

40 UDP. only UDP Interface module 748 must be changed. The applications are unaffected by such a change. 

Second, the applications on HTTP server 749 are Independent of the two-way data communication device with 
which HTTP server 749 is interacting. An application on HTTP server 749 can communicate with any two-way data 
communication device that includes the appropriate client and a nrxxJule to transmit and receive data over the two-way 
data communication network. These two tacts mean that an investment in developing an application is Insulated from 

45 either advances In two-way data communication devices, or advances in two-way data communicatfon network technol- 
ogy. 

Rgures 8A to 8D are a process flow diagram for one embodiment of this invention. Initially, when the user initiates 
communication over airnet network 750. client module 702 Initializes a work space in memory 716 of cellular telephone 
700 and then, in get home URL process 801 . stores a URL in the work space. According to the principles of this inven- 

50 tion. In one embodiment each cellular telephone that utilizes the airnet network has a home URL stored in a non-vola- 
tile memory that is used to retrieve a home card deck for the cellular telephone. In another embodiment, the cellular 
telephone obtains the home URL from server 749. Thus, in get home URL process 801 . client module 702 obtains the 
home URL Herein, a URL is an example of a specific entxxiiment of a resource locator. 

For example, in get home URL process 801 . client module 702 obtains a home URL. such as 

55 http7/www.libris.com/airnet/home.cgi 

and stores the home URL in the work space. The portion of the home URL. httpywww.librls.com. identifies a particular 
HTTP server. I.e. server 749. on the world-wide web. The portion of the URL. /airnet/home.cgi, specifies a particular 
common gateway interface program within CGI programs 761 . The use of a URL pointing to a server on the world-wkle 
web is illustrative only is not intended to limit the Invention to applications on the world-wide web. In general, cellular 
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telephone 700 obtains an identifier, i.e. a resource locator, of a home application on a home server that is executed by 
the server when the cellular telephone initially becomes active on airnet network 750. and stores the resource locator 
in the work space. 

Next in aeate HTTP request process 802. client module 702 converts the URL in the work space to a HTTP 

5 request. For example, for the above URL. create HTTP request process 802 generates a method field, such as 
GET /airnet/home.cgi HTTP/1 .0 
The GET method is part of HTTP. Thus, ttie format for the GET method is known to those skilled in the art. Also, this 
particular form of the method is used because a specific server connection is established by cellular telephone 700 and 
so Identification of the server is unnecessary. Nevertheless, briefly, this command instructs server 749 to execute appli- 

10 cation home.cgi and execution of application home.cgi in turn results in generation of a home deck and a sut>sequent 
transmission of the home deck to cellular telephone 700. HTTP/1 .0 specifies the HTTP version used by client module 
702 in cellular telephone 700. 

In addition to the method field, client module 702 In process 802 could also generate appropriate HTTP request 
fields to pass information to server 749 atx^ut the capabilities of client nrKxiule 702. The request fields can include infbr- 

75 mation such as lists of the MIME content-types acceptable to the client; lists of data encoding types acceptable to the 
client; user authentication and encryption scheme information for the server; the length in bytes of the message being 
sent to the server; and the Internet mail address of the user accessing the server. This list of information is illustrative 
only and is not intended to limit the Invention to the particular request fields described herein. Any request field defined 
by HTTP can be utilized by client module 702. However, in this embodiment, the defaults are utilized and so no HTTP 

20 request fields are generated. 

Typical HTTP methods that can be generated in HTTP request process 802 are a GET method for requesting either 
a TIL deck from server 749, or execution of a common gateway Interface program on server 749; and a GET method 
request to a common gateway interface program with data, e.g., a query string appended to the URL In either case, a 
URL is transmitted to server 749 within the particular message. After create HTTP request process 802 is complete, 

25 client process transfers to transmit request process 804. 

However, if the transmission control protocol Is used instead of UDP, client module 702 would access a TCP mod- 
ule in establish server connection process 803 that replaced UDP module 714. Since, in this embodiment. UDP Is used, 
estat)llsh connection process 803 is enclosed by a dashed line in Rgure 8A to Indicate that this process Is unnecessary 
when using UDP. 

30 In establish server. connection process 803. a virtual connection would be made over CDPD network 710 between 
TCP interface module 714 and a TCP interface module in HTTP server 749 so that data could be transmitted between 
cellular telephone 700 and computer 743 using TCP. e.g., buffers to support data exchange are defined. The establish- 
merrt of a TCP connection Is well-known and so is not described further. 

In Figure 8A. a clashed line connects establish server connection process 803 with establish client connection proc- 

35 ess 860, that is also dashed, that is performed by HTTP server 749. This indicates that both client module 702 and 
server 749 are required to complete process 803. 

When tiie TCP virtual connection is established, client module 702 tranters processing from establish server con- 
nection process 803 to transmit request process 804. Similarly, server 749 transfers to request received check 861 , In 
which server 749 waits until a request is received. Establish client connection process 860 is not needed for UDP and 

40 so HTTP server 749 initiates processing in request received check process 861. Process 860 is enclosed within a 
dashed line tx)x to Indicate that the process is used only for TCP. 

In transmit request process 804. the HTTP request is sent from the work area in telephone 700 to HTTP server 749. 
Again, a dashed line connects process 804 of client module 702 to request received check 861 that is performed by 
HTTP server 749 to indicate that the check Is dependent upon information from client module 702. When the transmis- 

45 sion of the request is complete, client module 702 transfers to response received check 806. 

Upon receipt and storage of the HTTP request, request received check 861 transfers to service request process 
862 in which HTTP server 749 initiates service of the received request. In service request process 862. If the HTTP 
request only seeks transfer of a static deck, HTTP server 749 retrieves the requested static deck from TIL decks 760. 
Conversely, if the request requires server 749 to obtain data from the Internet or to append data to a particular file. 

so server 749 launches the common gateway Internee application addressed in the request, and passes the data In the 
HTTP request to this application for f urtiier processing. 

For example, if tiie user of cellular telephone 700 requested a fax as in Figure 2F. tiie HTTP request Identifies a 
common gateway interface application in CGI programs 761 tiiat accepts as input data the telephone nunnber and grabs 
the information to be faxed. The CGI application generates an e-mail transmission to the fax gateway. Similarly, for a 

55 Stock quote, server 749. in response to the HTTP request, launches a common gateway imerface application that sends 
out a stock query over Internet 140 to a stock quote service provider using the tcksr tape symbol passed as input data 
by server 749 to the common gateway interface application. When the response to tiie stock query is received, the com- 
mon gateway interface application builds a PIDL deck that includes the data in the response to the stock query 

Upon conrpletion of servicing the request. HTTP server 749 converts the PIDL deck to a TIL deck and returns the 
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TIL deck to client module 702 teing UDP in transfer response process 863. that is connected by a dotted line to 
response received check 806 in dient module 702. As the TIL deck is transfenred, client nxxiule 702 stores the deck in 
memory 716. 

After the TIL deck is transferred, HTTP server 749 closes the process for responding to the message from cellLriar 
5 telephone 700. All the information needed by client module 702 to generate a user interface on display saeen 705 and 
for responding to any selection or data entry presented in the user interface is included in the TIL deck. Consequently, 
client module 702 only has to interpret the TIL deck and interpret the user input to transmit the next message to HTTP 
server 749. The state for the HTTP server is defined in the next message. Consequently, HTTP server 749 is stateless 
because HTTP server 749 does not retain state information concerning a response to a message after the message is 
10 transmitted. 

However, in another emtxxiimertt (not shovym). a server could retain state information concerning each interaction 
with a client module. For example, if the server transmitted a choice card to the client module, the server would retain 
state information indicating that a choice was pending from the client module. In this embodiment, when the user makes 
a choice, e.g., depresses key two to indicate choice two, the choice is transmitted to the server which in turn accesses 
15 the URL associated with choice two. If this URL addresses another application, the server executes that application. 
Thus, in this embodiment, the server retains state information concerning each interaction with a client module. In view 
of this disclosure, those skilled in the art can implement the principles of this invention utilizing a server that retains state 
information when such a client/server combination is advantageous. 

Returning to the present embodiment, when the TIL deck is received, client module 702 leaves response received 
20 check process 806 and transfers to process first card 808. However, if TCP is used instead of UDP, client module 702 
upon leaving check 806 would close the virtual TCP connection in transmission completed process 807. Upon closing 
the virtual TCP connection, processing would transfer to process first card 808. Again, transmission complete process 
807 is enclosed within a dashed line box to indicate that process 807 is used only with TCP. 

In process first card 808. dient module 702 parses the TIL deck and interprets the first card. Processing transfers 
25 from process first card 808 to generate display process 809. 

In generate display process 809. client module 702 passes the data to t»e displayed in the first card to display mod- 
ule 712. Display nxxiule 712, in response to the data, drives the text and images in the data on display screen 705. 
Generate display process 809 transfers processing to key press check 820 through node 81 3. In Figures 8A to 8D, any 
circular node with the same alphanumeric character and reference numeral is the same node. The circular nodes are 
30 used to establish connections between the various processes in the method of Figures 8A to 8D without duttering the 
figures with a number of connection lines. 

Client nrodule 702 waits in key press check 820 for the user to press a key on keypad 71 5 of cellular telephone 700. 
In this embodiment, cellular telephone 700 is assumed to have the capability to support two soft keys, a scroll-up key. 
a scroll-down key, a previous key, a next key. and keys zero to 9 that are configured in the standard telephone keypad 
35 configuration. In view of the following disdosure, if one or nrrore of these keys are not present, one of skill in the art can 
alter the method for the particular configuration of the cellular telephone keypad, or other two-way data communication 
device keypad. For exanrple. if the cellular telephone included a home key, the key press processing described more 
completely below would indude a check that detected when the home key was pressed and would in turn transfer to 
get home URL process 801. 

40 Briefly, tiie processes in Figures 8B to 8C, identify the key pressed by the user, identify the action required, and tiien 
trar^fer to a process that implements the action required. Specifically, when a key on the keypad is pressed, keypad 
nrxxjule 71 1 stores an identifier for the key in work memory 716 and notifies client module 702 of tiie key press. Upon 
receipt of the notification from keypad module 71 1 , client module 702 reads the storage location in work memory 716 
to determine ttie key pressed and transfers processing from key press check 820 to scroll key check 821 . 

45 In scroll key ched« 821 , client module 702 determines whetiier the user pressed either of the scroll keys. If a scroll 
key was pressed, processing transfers to adjust display process 822 and othenftrise to display card check 823. 

In adjust display process 822. dient module 702 determines which of the scroll-up or scroll-down keys was 
pressed. Client module 702 then sends information to display nrKxJule 712 so that the current display is either scrolled- 
up one line or scrolled- down one line. If the scroll key would move the display beyond a boundary of the current card. 

so the scroll key press is ignored in adjust display process 822, 

In response to the information from dient module 702. display module 712 adjusts tiie screen display on display 
screen 705. Client module 702 transfers processing from adjust display process 822 to key press check 820 ttirough 
node 813. 

If a scroll key was not pressed, processing is passed through scroll key check 821 to display card check 823. Qient 
55 module 702 takes action that depends on the particular type of card that is currentiy being displayed on display screen 
705. If the cun^ent card is a display card, dient nrxxlule 702 passes through display card check 823 to soft key check 
828. and otherwise transfers to choice card check 824. 

Assuming for ttie moment that the current card is not a display card, choice card check 824 determines whetiier the 
current card is a choice card. If the current card is a choice card, client module 702 passes tiirough choice card check 
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824 to choice key check 826. and otherwise transfers to data key check 826. 

Assuming for the moment that the current card is neither a display card nor a choice card, the current card must be 
an entry card, because in this en^bodiment only three card types are defined. Thus, client module 702 does not check 
for an entry card. Rather, data key check 826 determines whether a valid data key was pressed. In this embodiment. 
5 the data keys are keys zero to nine on the key pad. and the # key. In other entxxiiments. other combinations of keys 
could be defined as data keys. If the pressed key was one of the data keys, data key check 626 transfers to process 
data entry 827 and othenwse transfers to soft key check 828. 

In process data entry 827, client module 702 knows whetiier the predictive text entry process is turned-on, because 
one of the parameters on the entry card specifies whether to use the predictive text entry process, as described in 
10 Appendix I. which is incorporated herein by reference in its entirety. 

If the predictive text entry process is not turned-on. client module 702 in process data entry 827 enters the pressed 
key value In a text entry buffer in work memory 71 6 at the appropriate location. Also, client module 702 sends informa- 
tion to display module 712 so the value of the pressed key is displayed in the appropriate location on display screen 705 
by display module 712. 

15 If the predictive text entry process is turnedon« client module 702 uses the novel predictive text entry process in 
process data entry 827. as described more completely below with respect to Rgures 9, 10A to 10T and 1 1 . to deter- 
mine the letter to select from the set of tetters associated with the pressed key. After the predictive text entry process 
determines the appropriate letter, a value representing the letter is stored at the appropriate location in the text buffer 
in work memory 716. Also, client module 702 serxls information to display module 712 so that the letter is displayed in 

20 the appropriate location on display screen 705. Upon completion of process data entry 827. client module 702 transfers 
processing through node 81 3 to key press check 820. 

The previous description assumed that the current card was an entry card, but if the current card is a choice card, 
choice card check 824 transferred to choice key check 826. In generate display process 804 for the choice card, each 
of the choices are labeled according to information on the choice card and some or all of the choices are displayed on 

25 display screen 705. Thus, choice key check 826 determines whether the pressed key corresponds to one of the 
choices. If the pressed key is one of the choices, client nrxxlule 702. in one emtxxiiment sends information to display 
module 712 to indicate the selected choice. Client module 702 also transfers from choice key check 826 through node 
831 to store identifier process 850 (Rg. 8D). that Is described more completely betow. Conversely, if the pressed key is 
not one of the choices, choice key check 826 transfers to soft key check 828. 

30 Soft keys can be specified both for a deck as a whole and per card, i.e.. a physical key on the keypad is specified 
as a soft key as described more completely in Appendix I. Each soft key specification includes an identifier that ddines 
the action to be taken when the soft key Is pressed. 

When a soft key is specified for a decK the soft key remains in effect for the entire deck However, when a soft key 
is specified for a card, the card soft key specification tennporarily overides the corresponding deck soft key spedfica- 

35 tion. i.e., the deck soft key specification for the same physical key as the card soft key specification, while the card is 
visible, i.e., displayed on display screen 705. This override is done independently for the two soft keys. TTius, soft key 
check 828 transfers processing to first soft key check 829 if the key pressed is one of the two possible physical soft keys. 
Conversely, soft key check 828 transfers processing to next key check 840 (Rg. 8C). if neither of the two possible phys- 
ical soft keys is pressed by the user. 

40 In first soft key check 829, client module 702 determines whether the pressed key corresponds to the first soft key. 
If the pressed key is the first soft key, check 829 passes the active identifier for the first soft key to store identifier process 
850 through node 831 . Conversely, if the pressed key Is not the first soft key. processing transfers from check 829 to 
second soft key check 830. 

If the pressed key is the second soft key. check 830 passes the active identifier for the second soft key to store iden- 
45 tifler process 850 through node 831 . Conversely, if the pressed key is not the second soft key, e.g., aphysical key that 
can be defined as a soft key was pressed but nether the current deck nor the cun^ent card defines a soft key for that 
physical key, processing transfers from check 830 to key press ched^ 820 through node 813. 

When pressing transfers to next key check 840. client module 702 determines wheth^ the pressed key was the 
next key. If the next key was pressed, processing transfers to display card check 841 and othenvise to previous key 
50 check 846. 

If a di^lay card is the current card, the next key is used to move to another card in a deck, or alternatively to 
another deck. Thus, display card check 841 transfers processing to last card check 842 v/hen a display card is the cur- 
rent card, and otherwise to entry card check 843. 

Last card check 842 determines whetiier the cun-ent card is the last card in the deck. If the cun^ent display card is 
55 not tiie last card in the deck, last card check 842 transfers processing to read next card process 845, which in turn reads 
the next card in tiie deck and transfers through node 812 to generate display process 809. 

If the current display card is the last card in the decK the deck Includes an identifier that specifies tiie location to 
transfer to from the last card. This identifier can be a URL to another decK to a common gateway interface program, or 
an address for a card within the cun-ent deck, for example. Thus, last card check 842 transfers tiirough node 831 to 
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store identifier prcx:ess 850 when the current display card is the last card in the deck 

If the current card is not a display card but is an entry card, display card check 841 transfers to entry card check 
843. In this embodiment, the next key is the predetermined key used to indicate that all the data for an entry on an entry 
card has been entered. Thus, if the current card is an entry card, entry card check 843 transfers processing to store 
5 data process 844. 

Store data process 844 stores the data entered in at an appropriate location in memory that is specified in the cur- 
rent entry card. Typically, the data is combined as an argument with a URL and stored. Upon completion, store data 
process 844 transfers through node 810 to create HTTP request process 802 (Rg. 8A). 

When the next key is pressed, if the current card is neither a display card nor an entry card, the current card is a 
10 choice card. However, as indicated above, in this er*odiment client module 702 requires that the user make a choice 
and does not allow use of the next key. Consequently, if the current card is not an entry card, entry card check 843 trans- 
fers prcx^essing through node 81 3 to key press check 820. 

The previous discussion assumed that the next key was pressed and so next key check 840 transfened processing 
to display card check 841 . However, if the next key was not pressed, next key check 840 transfers processing to previ- 
15 ous key check 846. H the previous key was pressed, check 846 transfers to first card check 847 and otherwise returns 
processing to key press check 820. 

Rrst card check 847 determines whether the current card is the first card of a deck. If the current card is not the 
first card, processing transfers from first card check 847 to read previous card 849, which in turn reads the previous card 
and transfers to generate display process 809 through node 813. Conversely, if the current card is the first card. 
20 processing transfers to home deck check 848. 

If the current card is the first card in the home deck, there is not a previous card and so home deck check transfers 
processing to key press check 820 through node 81 3 and so the previous key press is ignored. If the current deck is not 
the home deck, home deck check 848 retrieves the identifier for the previous deck and transfers through node 831 to 
store identifier process 850. 

25 Store identifier process 850 is reached through node 831 from several different points. The operations in store iden- 
tifier process 850 are the same irrespective of the particular process that transfers to process 850. In each instance, an 
identifier is passed to store identifier process 850 and process 850 saves the Identifier in working memory 716. The 
identifier can be. for example, a pointer to another locatron in the current card, an address of another card in the current 
decK a URL to a dedt stored in working memory 716. a URL to a TIL deck in TIL decks 760 on computer 743. or per- 

30 haps, a URL to a common gateway interface program in CGI programs 761 on computer 743. Thus, process 800 
checks the stored identifier to determine the action required. 

Specifically, in identifier to current deck check 851 . client module 702 determines whether the identifier is to a card 
in the current deck If the kJentifier points to the current deck, check 851 transfers processing to retrieve cteta process 
852 and otherwise to URL to local deck check 853. 

35 In retrieve data process 852, client module 702 retrieves the information stored at the location indicated by the iden- 
tifier from working memory 716 and processes the information. Retrieve data process 852 transfers through node 812 
to generate di^lay 809 (Fig. 8A) that was described above. 

URL to local deck check 853 determines whether the identifier is a URL to a deck that is stored in working memory 
716, e.g., cached, tf the deck is stored locally, check 853 transfers to retrieve local deck 854 which in turn moves the 

40 local deck into the storage location for the cunent deck Retrieve local deck 854 transfers processing through node 81 1 
to process first card 808 (Fig. 8A). that was described above. 

If the klenlifier is neither to a location in the current deck nor to a local deck the identifier is a URL to an object on 
computer 743, Thus, in this case, check 853 returns processing to create HTTP request 802 through node 810. 

Process 800 continues so long as the user continues to enter and process the information provided. In this embod- 

45 iment process 800 is terminated, for example, either by the user powering-off cellular telephone 700, selecting a choice 
or entry card that discontinues operations of client module 702, or remaining inactive for a time longer than a time-out 
period so that client module 702 shuts itself down. 

To further illustrate the operations in process 800. consider the following example which is returned to client nrodule 
702 as a TIL deck in response to a HTTP request generated by process 802. For readability. Table 2 presents the deck 

50 in PIDL In this example, ail of the choices are for applications on the same server. However, in another embodiment, 
each URL could address any desired combination of servers. 
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TABLE 2 

EXAMPLE OF PIDL CHOICE DECK 

^ (PIDU 

(CHOICE) 

(CE URLs=httpy/wwwJlbris.com/airnet/nnn)News 
<CE URL=httpy/vvvwJlbris.corrVairnetAflnftw 
<CE URL=httpy/wAAW.IIbris.corn/airnet/sss)Sports 
VCHOICE) 
VPIDU 

15 

In process first card 808, client module 702 interprets the infbrnnation in Table 2 and transfers to generate display proc- 
ess 809. In generate display process 809. client module 702 sends information to display module 712 so that the user 
is presented with a list of three choices on display screen 705, i.e, a user interface for the choice card Is generated: 

20 

1. News 

2. Weather 

3. Sports 

25 Generate display process 809 (Fig. 8A) transfers to key press check 820 (Fig. 8B). When the user presses the two 
key on keypad 715, key press check 820 transfers through check 821 to display card check 823. 

Since the current card is a choice card, check 823 transfers processing to choice card check 824. which in turn 
transfers to choice key check 826. Since the two key was pressed and that key is a choice key. check 826 transfers 
processing to store identifier process 850 (Rg. 8D). In process 850, client module 702 stores the URL corresponding 
30 to two. i.e, 

URL=http:y/www.libris.corn/airnet/www 
in working memory 716. 

Since this URL is to an object on computer 743, processing transfers through checks 851 and 853 to create HTTP 
request process 802. which in turn generates the request. When the HTTP request is transmitted to server 749. as 
35 described above with respect to process 804, server 749 in service request process 862 retrieves deck www from TIL 
decks 760. An example of the deck is given in Table 3. Again for readability, the deck in present herein in PIDL 

TABLE 3 

4^ EXAMPLE OF A SECOND PIDL CHOICE DECK 

(PIDU 
(CHOICE) 

<CE URL=http7/www.libris.conrVairnet/www-1 World 

45 

<CE URL=http7/www.libris.com/airnetAfvww-2)National 
<CE URL=:http7/www.libris.com/airnet/www-3>State 
<CE URL=http7/wwwJibris.com/airnetAAmw-4}Local 
(^CHOICE) 
VPIDD 



55 The deck in Table 3 is transmitted to cellular telephone 700 and stored in memory 71 6. as described above with respect 
to process 806. The choice card is processed in process 808 and displayed in process 809. As a result of process 809. 
the user is presented with a list of choices: 

1. World 
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2. National 

3. State 

4. Local. 

5 When the user makes another selection, the same sequence of processes as described above for the first choice 

card is executed by dient module 702. and another URL is stored that points to a program on server 749 that retrieves 
the desired weather information and generates a deck with that Information. This deck Is transferred to cellular tele- 
phone 700 and displayed. 

As describ>ed above, If the current card is an entry card and a key is pressed, client process 702 reaches data key 

10 press check 826 (Fig. 8B). If the pressed key is a valid data key. check 826 transfers to process data entry 827. 

In one embodiment, process data entry 827 uses a novel predictive text entry process for text entry. Recall that on 
a typical telephone keypad, the keys are labeled with both a nunt^er and two or three letters. For example, the two key 
is also labeled alx. This leads to some ambiguity when using the telephone keypad to enter text Is the user attempting 
to enter an a. b, or c when the two key is pressed? 

15 In one prior art method, two keystrokes were required to enter each letter of text. The first keystroke identified the 
first key and the second key stroke identified the specific letter desired on the first key. For example, to enter the letter 
s. the user would first press the seven key that is labeled with letters p. r. and s. Next the user would press the three 
key to select the letter s. While this method may work well for short sequences that consist of only three or four letters, 
the method does not work well for English text. For example, if the user has already entered th and then presses the 

20 three key that Is labeled with letters d. e. and f . almost always the desired next letter Is the letter e. Therefore, making 
the user press the two key is an extra and unnecessary step. 

Client nxxJule 702 of this irrvention utilizes a novel predictive text entry process to reduce the number of key strokes 
required to enter text using a telephone keypad, or any similar keypad. Using this process, in most cases a single key 
stroke suffices to enter a single letter. 

25 While this embodiment of the Invention is described in terms of a telephone keypad, the principles of the invention 
are not limited to only a telephone keypad. In general, the process desalbed more completely below, can be extended 
to any keypad where a single key is used to enter two or more letters. Further, the process is not limited to only letters, 
but rather is applicable to any keypad where a single key is used to represent two or more characters. In view of the 
following disclosure, those skilled in the art can use the principles of the predictive text entry process in a wide variety 

30 of applications. 

The system for predictive text entry includes a predictive text entry module 901 that in this embodiment is Included 
in client module 702. keyboard module 71 1. and a letter frequency table 902 that is loaded into memory 716. when cli- 
ent module 702 is activated. Predictive text entry module 901 Is used In process data entry 827 when specified by the 
current entry card. Predictive text entry nrxxJule 901 performs routine buffer management processes, that are known to 

35 one of skill in the art and so are rxrt described further to avoid detracting from the process. 

Predictive text entry module 901 stores a letter entry lor each letter entered in a text buffer 903 in memory 716. In 
this embodiment, letters Q and Z are assigned to the one key and the zero key is used to enter a space, period, and 
comma, i.e., the zero key provides punctuation. However, these assignments are illustrative only, and are not intended 
to limit the inverrtion to this particular embodiment 

40 The first letter entered is placed at the left end of the buffer and each additional letter is placed in the left rrrast 
unused space in buffer 903. Thus, the last letter entered in text buffer 903 is the right most character. Letter frequency 
table 902. sometimes referred to as a table of predictive letter entries, is a look-up table where each entry In the look- 
table is addressed by three irxiices. The first two Indices represent the two most recently entered letters in text buffer 
903 and the third index represents the key that was pressed. Each predictive letter entry stored in letter frequency table 

45 902 defines which of the letters associated with the pressed key to use given the previous two letters. For example, 
since the is a commonly occurring string, the entry in table 902 addressed by (t h. 3) returns e, or more concisely the 
predictive letter entry 2 is returned to indicate that the second letter of the group of letters d. e, and f associated with 
the three key Is the predicted letter. Of course, letter frequency table 902 could be altered to return more than a single 
letter. 

so In this emtjodiment, letter frequency tal)Ie 902 was empirically generated using a collection of e-mail. Appendix II 
is a computer program listing that was used to generate letter frequency tat>le 902 ttiat is illustrated in Hgures 10A to 
10T Briefly, the computer program Implements a process that sequentially steps through the data provided and (i) for 
each possifcile single letter determines the most likely letter that follows for each key on the keypad: and (ii) for each pos- 
sible combination of two letters determines the most likely letter that follows for each key on the keypad. In this embod- 

55 iment the most likely letter is the letter having the greatest frequency after the single letter. Similarly, the most likely 
letter is the letter having ttie greatest frequency after the combination of two letters. If there is a tie in the frequency, the 
first letter associated with a key is selected. Of course, oth©' measures of likelihood couW be used to generate the 
entries in table 902. 

Thus, in Figures 10A to 10T. the first of the ten columns. I.e., the left most column, is the two letter sequence and 
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the first row. i.e., the top row is the keys on the key pad used to enter text. A combination of an entry in the first column 
and a key in the top row is used to select the predicted text entry. Thus, using the example of th, this two key sequence 
appears in the first column of Figure 10O. When the three key is pressed, the letter In the row with th as the first entry 
and in the column with three as the first entry, i.e., e. is retrieved. Alternatively, if the four key is pressed, letter i is 

5 retrieved from the table. 

In this entKxJiment. table 902 is a buffer of two bit numbers. Each two l:»t number has a value in the range of zero 
to three, and the two bit number represents a predicted letter for the pressed key. Thus, for a two key labeled with letters 
A, B and C. a zero represents A; a one represents B; and a two represents C. In general, the number of bits used is 
determined by the key that represents the maximum number of characters. In this embodiment, the maximum number 

10 of characte-s represented by a key is three. The number of storage bits required is an integer S where S is the smalls 
number such that 2**S is greater than or equal to the maximum number of characters represented by a key 

In this emtxxiiment. three indices 10. 11 . and \2 are used generate a table index that in turn is used to access a par- 
ticular predictive letter entry in table 902 of two bit numbers. Each letter is represented as a number, i.e., a letter entry, 
with letter A being zero, letter B being a one. letter C being a two. and so forth with letter Z being twenty-five. A space 

75 element is assigned a space element value of twenty-six. Thus, in this emljodiment, there are twenty-seven possilale 
characters. 

Upon the initial entry to process 1100 (Fig. 11). letter indices iO. i1, arKi i2 were set to twerrty-six In the initial 
processing of the entry card to indicate that the text buffer Is empty. Also, as explained more completely below, as each 
letter of text is entered, letter indices iO and 11 are updated and stored in memory 716. 

20 However, in another embodiment, an initialize indices process is the first operation In predictive text entry process 
1 100. In this emt»odiment, for the first letter entered, letter indices iO and i1 are set to twenty six; for the second tetter 
entered, letter index iO is set to twenty six and letter index i1 is set to the value of the letter In text buffer 903; and for all 
letters entered after the first two, the value associated with next to the last letter in text buffer 903 Is assigned to letter 
IrxJex iO and the value associated with the last letter In text buffer 903 Is assigned to letter Index II . 

25 Punctuation key check 1101 determines whether the zero key was pressed. I.e.. the key selected to represent 
punctuation. 

If the zero key was pressed, processing transfers from check 1101 to process punctuation entry 1102. Process 
punctuation entry 1102 sets Index 12 to twenty-six, arKJ sends the space element value to display letter process 1 1 08. 
Display letter process 1 1 08 transfers the space element value to display nnodule 712 which in turn drives a space in the 
30 text entry on display screen 705. This completes the operation of process data entry for a zero key press and so 
processing returns to key press check 820. 

If the zero key was not pressed, processing transfers through punctuation key check 1101 In data entry process 
1 1 00 to key one-to-nine check 1 103, I.e.. to a data entry key check. If the pressed key was any one of keys one to nine, 
check 1 103 transfers to set letter index process 1 104 and otherwise to rotate last entry process 1 109. 
35 In set letter index process 1 1 04. one is subtracted from the numeric value of the pressed key and the resulting value 
Is assigned to index 12. Set index process 1 1 04 transfers to generate table index process 1 105. 

Generate table index process 1 105 coml^nes indices iO. i1 and \2 to create a table index. In this emtxxJiment. table 
index TABl£JNDEX Is defined as: 

TABLEJNDEX = {((iO * 27) + II) * 9) + i2 
40 Upon completion of generate tattle index process 1 105. generate text entry process 1 106. retrieves the two bit value in 
the table at the locaton pointed to by table index TABLEJNDEX and converts the two bit value to a letter represented 
by the two bit value. 

Generate text entry process 1 106 transfers to update index process 1 107. which in tum stores the value of letter 
index i1 as letter index iO; stores the value of the retrieved letter in tetter Index i1 ; and stores the predicted tetter in text 
45 buffer 903. While this step assumes that letter Indices iO. and 11 are stored and accessed each time in process 827. 
atteratively. the last two letters In text buffer 903 can be retrieved and assigned to indices iO and i1. respectively, as 
described above. 

Update index process 1 1 07 transfers to display letter process 1 1 08. Display letter process 1 1 08 sends information 
to display rruxjule 712 which in turn generates the predicted letter on display screen 705. 

so If the pressed key Is not one of keys one to nine, i.e. Is not a data entry key, processing transfers from check 1 103 
to rotate last entry 1 109. Recall that data key check 826 determined whether the pressed key was one of the zero to 
nine keys, or the # key. Thus, since checks 1101 and 1 1 03 determined that keys zero to nine w^e not pressed, the only 
key press remaining Is the # key, i.e.. the rotate entry key, which indicates the user wants a letter different than the one 
entered last in text buffer 903. In rotate last entry 1 109, the last character, I.e., the right most character, in text buffer 

55 903 is replaced by the next character in the set of characters assigned to the last key pressed before the # key was 
pressed. Again, the use of the # key is fliustrative only and is not intended to limit the invention to the use of that partic- 
ular key to rotate an entry. 

For example, if the last character In the text buffer 903 was a t and the # key is prised, process 1 109 changes the 
t to u. If the # key is pressed again, the u Is changed to a v. Atternatlvely. If the last character in text buffer 903 was a u 
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arxJ the # key is pressed, process 1 109 changes the u to a v. tf the last character in text buffer 903 was a v and the # 
key is pressed, process 1 109 changes the v to a t If index i1 is stored, as the last character in text buffer 903 is rotated, 
index i1 is updated. 

Text entry in cellular telephone 700 in different languages or contexts can be supported by using different letter fre- 

5 quency tables. For example, for plumbers, the prediction table can be teased on text about plumbing prTCedures. For 
Frenchmen, the prediction tat)le can be based on French text. Also, multiple letter frequency tables coukJ be stored in 
cellular telephone 700. or selectively transmitted to cellular telephone 700, and a particular letter frequency table would 
be selected on an entry card. 

In addition, an entry in the table can be more that a single letter, and thus save even more key strokes. For example. 

10 if the text buffer contains sche then typing a 3 could return dule rather than just d. Further, this novel method of text 
entry can be utilized with other than a cellular telephone. The method is apf^icatHe to any device that has several char- 
acters assigned to a single key on a keypad. 

In the atx>ve embodiment the English alphabet and a space element were used as the character set. Thus, the 
number 27 used in defining the table index is just the number N of characters in the set. Similarly, the nuntfjer 9 used 

15 in defining the teitDle index is just the number M of keys in the keypad that represent two or more different characters. 
Hence, predictive text entry method of this invention is not limited to text and Is directly applicable to any keypad where 
each key represents a plurality of different characters. 

In the embodiment of Figures 7. 8. and 9, client module 702 and server module 749 communicate over CDPD net- 
work 710. However, this architecture is illustrative only of the principles of the invention and is not Intended to limit the 

20 Invention to the particular architecture described. Client nnodule 702 and server module 749 can use a wide variety of 
two-way data communication links to exchange resource locators, e.g., URLs, and TIL decks. For example, the commu- 
nications link could be a switched voice circuit in which the client module and server module comrrujnicate using 
modems. Alternatively, the communications link could be any other packet switched network, so long as there Is some 
way for client module 702 to get requests to server module 749 and for server module 749 to send data back to dient 

25 module 702. Further, a special purpose server could be used in place of HTTP server 749. For example, the princples 
of this invention can be used over various data transport mechanisms Including circuit switched data and packet 
switched data. These data transport mechanisms are being defined and implemented for most of the cellular networi^ 
standards including GSM. TDMA. and CDMA. 

In the configuration of airnet network 750 (Fig. 7), dierrt module 702 communicated directly with a server computer 

30 743. In another embodiment, as illustrated in Figure 5. the two-way data communication device first communicates with 
an airnet network translator 500 that in turn communicates with the appropriate server. In this embodiment, the opera- 
tion of two-way data communication devices 100. 1 01 . and 1 02 Is similar to that described above for cellular telephone 
700. except the method f iekJ in the request generated in process 802 has a different form. For example, using the same 
information as before, the method f iekj in this embodiment Is: 

35 GET http://www.librlacom/airnet yhome.cgi?&cost=1 ANTP/1 .0 

The method f i^d includes the full address of the server, the expected cost of the service, and the version of the protocol 
used for communicating with airnet network translator 500. The two-way data communication devrce transmits the 
HTTP request Including the complete URL to airnet network translator 500. 

Rgure 1 2 is a more detailed block diagram tiiat illustrates the structures in one embodiment of airnet networi^ trans- 

40 lator 500. according to the principles of this invention. In this ent^odiment airnet network translator 500 is a computer 
running under the UNIX operating system with an interface to CDPD network 710. Such computers are well known to 
those skilled in the art. Thus, herein only the structures and processes that must be added to such a computer are 
described. 

Airnet network translator 500 supports internet protocol (IP) connections over CDPD network 710 and with each 
45 computer network with which translator 500 can interact. In this embodiment, each of the modules in network translator 
500 are processes that are executed by the processor in the computer. Confrol module 1201 is a daemon that listens 
for transmissions over an IP connection from CDPD network 710. When control module 1201 accepts a transmission, 
control module 1201 spawns an Al^ request processor 1204. which in this embodiment is a process, as indicated 
above. While in Rgure 1 2, only one ANT request processor 1 204 is shown, there is an ANT request processor spawned 
50 for each transmission that control module 1201 accepts and tiie ANT request processor remains active until the com- 
munication is terminated. 

Rgure 1 3 is a process flow diagram that illustrates the operation of ANT request processor 1 204. This process flow 
diagram considers transmissions that utilize both TCP/IP and UDP/IP. However, the processes that are specific only to 
TCP/IP are enclosed in dashed-line boxes. Upon being spawned for a TCP/IP. in establish connection process 1300, 
55 ANT request processor 1204 establ^hes a TCP connection using a TCP module in the sender with the dient module 
over CDPD network 710. After the connection is established processing transfers from process 1300 to request 
received check 1301. 

If UDP Is being used, upon being spawned ANT request processor 1204 initiates processing in request received 
check 1 301 . In check 1 301 , ANT request processor 1 204 determines whetiier the request from cellular telephone 700 
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(Fig. 12) has been received and stored in mennory 1210. Memory 1210 r^resents both RAM and non-volatile memory 
in this ennbodiment When the request has been received and stored, processing transfers from check 1301 to retrieve 
data process 1302. 

In retrieve data process 1302, ANT request processor 1204 retrieves infornretion concerning the source of the 

5 URL, i.e.. client module 702 of cellular telephone 700 from customer database 1213. and the destination specified in 
the URL. i.e.. the designated server, from server database 1212. Both databases 1212 and 1213 are stored in memory 
1210. A customer r«x)rd in database 1213 includes, for example, a carrier address, e.g.. an IP number, an airnet net- 
work translator account number, tailing information, and server subscriptions. A server record in database 1212 
includes a server IP address, name, category, and class of service. Class of service refers to the pricing of the service. 

10 e.g., basic services, premium services, or pay-per-view services. Other pricing schemes can be supported in other 
implementations. When the information is retrieved for the server and service specified in the URL, and for the cus- 
tomer, processing transfers to valid request che<^ 1303. 

In valid request check 1303, ANT request processor 1204 determines, for example, whether client module 702, i.e., 
the customer, is authorized to access airnet network translator 500; whether client nrradule 702 is authorized to access 

75 the server specified in the URL; whether the specified server is available through translator 500; and whether the spec- 
ified server supports the requested service. Thus, valid request check 1 303, validates the client the server, and the di- 
ent/server pair Also, since an estimated cost is included in the request, the status and credit limits on the customer's 
account could be checked to determine whether the estimated cost is acceptable. If all of the checks are true, process- 
ing transfers to create HTTP request process 1306. Conversely, if any one of the checks is untrue, valid request check 

20 1 303 passes information corKierning the error to return error process 1 304. 

Return error process 1304 launches a CGI program stored in memory 1210 based on the information received and 
passes appropriate information to the CGI program. The CGI program builds an appropriate PIDL deck describing the 
en-or and converts the PIDL deck to a TIL deck, as described above. When the TIL deck describing the en-or is com- 
plete, return error process 1304 transfers processing to log transaction process 1315 that is described more completely 

25 below. 

If all the checks in valid request check 1303 are true, create HTTP request 1306 converts the request in memory 
121 1 to a request specific to the server specified, which in this embodiment is a HTTP request. For example, for the 
above request create HTTP request process 1308 generates a method field, such as 
GET/airnet/home.cgi?&client=xy2&cost=1 HTTP/1.0 
30 In this embodiment, the method field includes the same information as in the embodiment described al>ove, and in addi- 
tion, the method field includes a client identif icaton and the estimated cost. 

After create HTTP request process 1306 is complete. ANT request processor 1204 accesses TCP module 1203 in 
establish server connection process 1307 for TCP/IP and transfers to secure transmission check 1308 for UDP/IP. In 
establish connection process 1307. a connection is made between the server designated in the client request and tiie 
35 TCP interface module (not shown) so that data can be transmitted between airnet network translator 500 and the 
server. When the TCP connection to the server is established, ANT request processor 1204 transfers processing from 
estat>lish server connection process 1307 to secure transmission check 1308. 

In secure transmission check 1 308, ANT request processor. 1204 determines whether the HTTP request from the 
client requested a server that utilize a protocol that supports enayption. If such a server was requested, processing 
40 transfers to negotiate process 1 309 and othenA/ise to transmit request process 1310. 

In negotiate process 1309, ANT request processor 1204 negotiates an encryption technique with the server. Upon 
completion of the negotiation, processing transfers from process 1309 to encryption process 1311. In encryption proc- 
ess 131 1 , the HTTP request is encrypted using the negotiated encryption technique, and then processing transfers to 
transmit request process 1310. 
45 In transmit request process 1310, the HTTP request is sent from memory 1210 to the HTTP server. When the 
transmission is complete. ANT request processor 1204 goes to result received check 1312. 

As described above, upon receipt of the request, the HTTP server services the request. Upon completion of serv- 
icing the request, the HTTP server returns either a PIDL deck or a TIL deck to airnet network translator 500. The deck 
is stored in memory 1210. If the server does not convert the PIDL deck to a TIL deck, the translation is done by airnet 
so network translator 500. 

When the deck is received and stored, ANT request processor 1204 transitions from check 1312 to transmission 
completed process 1313 for TCP/IP and to secure transmission check 1314 for UDP/IR ANT request processor 1204 
closes the TCP circuit with the server in transmission completed process 1313. Upon closing the server TCP connec- 
tion, processing transfers to secure transmission chedc 1314. 
55 If the server utilized encryption, the deck stored in memory 1210 is encrypted. Thus, secure transmission check 
1 314 transfers processing to decryption process 1316 if encryption was used and otherwise to log transaction 1315. 

In decryption process 1316. the encrypted deck is decoded and stored in memory 1210. /Uso. after the decoding, 
if the deck must be converted to a TIL decK the translation is performed. Decryption process 1316 transfer to log trans- 
action process 1315. 
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In log transaction process 1315. ANT request processor 1204 writes a desaiption of the transaction to transaction 
log 1211 in mennory 1210. In this enixxlimerTt. each transaction record includes a customer iderrtitication, a server 
identification, time required for the transaction, cost of the transaction, and a completion code. In one enrtxxliment. for 
security purposes, each cellular telephone is assigned to only one cu^omer and only one account. 

5 After the transaction is logged, processing transfers to transmit result 1317. In transmit result 1317. AIMT request 

processor 1204 returns the deck to client 702, After the ded^ is transmitted, ANT request processor 1 204 is terminated. 

In one emlx)clment. if an airnet network translator is fully loaded and another transmission comes in. the translator 
returns the address of another aimet network translator and refuses the transmission. The cellular telephone transmits 
the message to the other airnet network translator. In yet another embodiment, all incoming transmissions are directed 

10 to a router. A plurality of aimet network translators are connected to the router. The router monitors the status of each 
trarrelator. Each incomir^ transmission is routed to the least Ixisy translator, which in turn responds to the transmission 
arKi performs the necessary operations for continuing communications with the client module. 

In the at)ove description of client module 702. module 702 interacted with components within the cellular telephone 
to perform the various operations specified by the user. To insulate client nrxxJule 702 from the exigencies of varioiB 

15 cellular telephones to the extent possible, a general architecture for client module 702 is described more completely 
below. This general architecture is designed to have specific manager modules that interact with the nrodules described 
above within the cellular telephone and to provide standard information to the remaining manager modules within client 
module 702. The manager modules with client nrKxJule 702 form an interpreter that interprets TIL decks to generate a 
user interface; interprets data input by the user; and interprets the TIL decks so that the data input by the user is com- 

20 bined with an appropriate resource locator and either a message is sent to an appropriate server, or another local TIL 
deck is interpreted by client module 702. While this embodiment is for a cellular telephone, the manager modules are 
generic and so are applicable to any client module in a two-way data comrtKinication device. 

This approach limits the modifications that must be made to client module 702 to implemerrt the principles of this 
invention in a wide variety of two-way data communication devices over a wide variety of two-way data communication 

25 networks. Also, in the above embodiment, client module 702 supported communications and interactions over the cel- 
lular telephone network. However, client module 702 can also support local services on cellular telephone 700. Typical 
local services includes local messages, an address book, and preconfigured e-mail replies, or any combination of such 
services. 

In this embodiment, client module 702 includes a plurality of manager modules including a navigation manager 
30 nrKXiule 1401 , a network manager nrxxjule 1402. a TIL manager nK)dule 1403. an archive manager nrxxlule 1404. a local 
manager module 1405. an event rrranager module 1406, a timer n^nager module 1407. a user interface manager mod- 
ule 1408, a memory manager module 1409, and a device dependent module 1410. 

Navigation manager module 1401 handles card and deck navigation as well as managing any caches. Navigation 
manager module 1401 owns and manages a history list and as well as a pushed card list In addition, navigation man- 
35 ager nxxJule 1401 functions as the nrtain line of client module 702; does all event distribution; and supports local serv- 
ices. 

For local services, like local message store, there are two basic approaches tiiat can be used. Rrst, local services 
are implemented in a CGI-like manner. Each local service has an entry point which is called with an argument list. A 
TIL deck is returned via tiie event manager. From that point on. tiie TIL deck is processed in the standard manner. This 
40 approach limits local services to the same constraints as remote services. A less restrictive approach is to allow the 
local service to f iekJ events instead of the standard event loop. The local service would construct TIL cards on-the-f ly 
and feed them to user interface manager 1406. Note tiiat the local sen^ice would need to cooperate with the standard 
event loop witii regard to the history tiie pushed card list, and any other state that is nornrtally managed by the event 
loop. Table 4 is a listing of processes for the architecture for navigation manager module 1401. 

45 
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TABLE 4 

ARCHITECTURE FOR NAVIGATION MANAGER MODULE 1401 
ProcessEvents (void) ; 

PushLocation (void * location. Boolean forStack) ; 
void * PopLocation (Boolean forStack) ; 
void * CurrentLocationO ; 
struct LOCAL_SERVICE { 
char name [50] ; 

FUNC HandleEvent (Event * pevent) ; 
FUNC StartLocalService (void) ; 
FUNC StopLocalService (void) ; 

}; 

static LOCAL_SERVICE localServices []={... } ; 
STATUS HandleEvent (Event * pevent); 
STATUS StartLocalService 0 ; 
STATUS StopLocalService ( ) ; 



30 Routine ProcessEvents is the main entry point for event processing in client module 702. Typical events include key 
presses on the keypad, choice selection for a choice card, text entry for an entry card, netvrork events, and history 
events. Routine ProcessEvents can be called at any time to process an event or events. Routine ProcessEvents does 
not return until all events on a queue generated by event manager module 1406 are processed. If a local service is run- 
ning, events are distributed to the local service before being processed by routine ProcessEvents. 

35 The remaining routines in Table 4 are called Internally to navigation manager nrxxlule 1401 and by local services. 
Routine PushLocation pushes a location on the history list and issues a request for that location. The forStack flag indi- 
cates a stack push of local cards. 

Routine *PopLocatlon pops a location on the history stack and issues a request tor the top location of the history 
stack. In routine ^PopLocation the forStack flag indicates that all cards since the last stack push should be popped. 

40 Routine XurrentLocation returns the current location the current URL being displayed. 

As Shown in Table 4. each local service provides a number of functions. If a local service is running, function Han- 
dleEvent. the local service's event handler, Is called before any processing by navigaton manager nrK)dule 1401 . tf the 
event is handled by the local service, the event is not processed any further. 

Function StartLocalService is the local services start function. Function StartLocalService is called before any 

45 events are distritxjted to the local function. Similarly, function StopLocalService is the stop functfon for the particular 
local service. Function Stq^LocalService is called when no more events are distributed to the local servk^e. 

Network manager module 1402 insulates the rest of client module 702 from the ^ecific networking protocol used 
over the cellular telephone network. Network manager module 1 402 delivers requests to the server specified in the URL 
via the cellular telephone network interface; segments re^nses from the server for lower latency; delivers responses 

50 from local services to navigation module 1401 via event module 1406; handles request/response cycle (e.g. cancella- 
tion, retry strategy) with the server over the cellular telephone network; can receive asynchronous messages from the 
server: performs memory management of TIL decks; performs caching of TIL ded^s; harKlles all negotiations concern- 
ir^g protocols and server scaling with the server; handles any encryption for information exdnanged between cellular tel- 
ephone 700 and the server. 

55 In sonre cellular telephone, the maximum message size is fixed. However, for UDP and TCP messages, a more 
direct interface is used that bypasses this limitation of message passing. It is important to avoid copying network data 
from memory buffer to memory buffer as such copying increases the memory "high water nrrark" as well as decreases 
performance. Since different cellular tel^^hones have different interfaces for delivering network data, network manager 
module 1402 manages the network data. In this way. network data is only copied from the network buffer for long-term 
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storage. 

When a message or reply arrives, network manager nxxlule 1402 uses event manager module 1406 to report that 
fact. However, access to the data by other manager modules in client module 702 is through a protocol that allows stor- 
age of data in a variety of fashions on different telephones. Any transparent, short-term caching of TIL data is handled 
5 by network manager module 1402. Table 5 is one architecture for network manager module 1402. 

TABLE 5 

SPECIFICATION FOR NETWORK MANAGER MODULE 1402 

10 — . 

typedef short TID; 

void NMJnit(void); 

void NM_Terminate(void): 

15 TID NM_Send Request (void *requestData. int length, Boolean ignoreCache); 

NM_CancelRequest (TID TRANSACTIONId); 

NM_DataType(TID TRANSACTIONId); 

NM_GetData(TID TRANSACTIONId. void *data, int *length. Boolean *conplete); 

20 

void *NM_HoldData (TID TRANSACTIONId); 
NM„ReleaseData(TID TRANSACTIONId); 
TID NM_StartData(int data Type, char *requestData, Int length); 
25 STATUS NM_EndData(TID TRANSACTIONId); 

STATUS NM_SetDataLength (TID TRANSACTIONW, int length): 
STATUS NM^GrowDataLength (TID TRANSACTIONId, Int grow); 
int NM_GetDataLength(TID TRANSACTIONId); 
void *NM_GetDataPointer (TID TRANSACTIONId); 
STATUS NM_DeliverData (J\D TRANSACTIONId); 

35 

Network manager module 1402 iderrtifies each network data transaction by a 16-bit transaction identification code 
TID. Network manager module 1402 increments transaction identification code TID by one for each new transaction. 
Transaction identification code TID rolls over after Oxffff. 

Routine NMJnit initializes network manager module 1402 and so is called before any other calls in network man- 
40 ager module 1402. Routine NM_Terminate closes processing of network manager module 1402 and so is called after 
alt other calls in network manager module 1402. 

Network manager module 1402 uses routine TID NM_SendRequest as the standard process of sending a request 
to the server. Pointer *requestData In the call to routine TID MN_SendRequest is defined by the server protocol. Simi- 
larly, the state, e.g.. the Boolean value, of variable ignoreCache is used to indicate whether any cached replies should 
45 be ignored. After sending the request, this routine returns a server transaction identification code TRANSACTIONId. A 
local service can also send a request to the server. 

When the user instructs client module 702 to cancel a request, network manager module 1402 calls a routine 
NM_CancelRequest with cellular telephone transaction identification code TID and server transaction identification 
code TRANSACTIONId. Routine NM_Cancel Request issues a command to the server to cancel the specified request. 
50 When data are received from the networK the data can be either a response to a request sent by routine TID 
MN_SendRequest, or by a local servica Thus, in response to receiving data from the server, network manager module 
1402 generates an event that includes server transaction identification code TRANSACTIONId and the type of data 
DATAType. For replies to requests sent by routine TID MN_SendRequest. server transaction identification code 
TRANSACTIONId is the same as tiie one returned by the matching call to routine TID MN_SendRequest and data type 
55 DATAType indicates that the data is a response. For local service originated messages, server transaction ID is new. 
and data type DATAType depends on whether the data is an e-mail, pushed TIL. or another type. 

After the network event is received by event manager module 1406. and navigation manager nxxiule 1401 distrib- 
utes control of tfie event to network manager module 1402. network manager module 1402 users the server transaction 
identification code TRANSACTIONId and the remaining routines in Table 5 to process the data. 
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Routine NM_DataType is us^ to return the particular data type dataTYPE, e.g. reply. MIME, server pi^h. etc. Rou- 
tine NM_GetData sets a pointer to the data identified by server transaction identification code TRANSACTION Id. 
retrieves the length of the data, and determines whether ail the data has been received. The interface provided by this 
routine allows the first part of a data stream, e.g. the first card of a TIL deck, to be processed by client module 702 

5 before the rest of the deck is received. 

Routine NM_HoldData is called before calling routine NM_GetData to hold the data and thus ir^ure that the data 
remains valid during processing by client module 702. tf the data is not hekj. the data can be deleted or moved with the 
internal buffers of network manager module 1402. If the data is held, routine NM_Re!easeData is called after network 
data has been proc^sed to release the data. 

10 Routines TID NM_StartData, NM_EndData. NM_SetDataLength, NM_GrowDalaLength. NM_GetDataLength. 
NM_GetDataPointer, and NM_DeliverData are used internally by network manager module 1402. and by local services 
to ddiver data By allowing local services to use these routines, the same tnjffers can be used to store tx)th network 
and locally generated data thereby reducing the amount of memory required to support client module 702. 

Routine TID NM_StartData creates a new data transaction and triggers a data delivery event. Routine 

75 NM_EndData is called when all data for the given server transaction identification code TRANSACTIONId has been 
transmitted. Routine NM_SetDataLength sets the data segment to a given length and nrtay cause the bcation of the ^ 
data to change. Routine NM_GrowDataLength grows the data segment by a given length and also may cause the loca- 
tion of the data to change. Routine NM_GetDataLength returns the length of the data segment. Routine 
NMjGetDataPointer returns a pointer to the data. This routine is preferably called before writing into the data buffer. 

20 Also, this routine is preferably called whenever the data's location may have changed. Routine NM.DeliverData can be 
called when at least one card has been stored to reduce latency while the other cards are being generated. 

TIL manager module 1403 insulates the rest of client module 702 from changes to the TIL specification. The inter- 
face provided by TIL manager module 1 403 has the following characteristics: removes the need for parsing by the rest 
of client nrKxjule 702; uses cursors to avoid generating data structures on-the-fly; does not need an entire deck to oper- 

25 ate; and handles TIL versioning. 

Each TIL deck contains a major and a minor version number. The minor version number is incremented when TIL 
changes in a way that does not break existing TIL manager modules. The major version number is incremented for non- 
compatible versions of TIL. 

Each TIL deck has the same hierarchy. One embodiment of this hierarchy is presented In Tatjie 6. In Table 6. inden- 
30 tation is used to represent the relationships of the various hierarchical levels. 

TABLE 6 
TIL DECK HIERARCHY 

deck 

opt. ions 
sof tkeys 

options 

card 

options 
sof tkeys 

options 
formatted text 

formatted lines 
entries 

options 

formatted line 

55 

The interface presented in Table 7 for TIL manager module 1403 is designed with the assumption that TIL is a direct 
toKenization of PIDLas desaibed in App)endix I. However, the interface does not have any dependences on that tokeni- 
zation and can support other PIDL encoding techniques. Given the atx)ve assumption, the opaque pointers described 
below are actual pointers into the TIL deck itself. A rudimentary object typing scheme leased on where in the deck the 



40 



45 



29 



ISOOCID: <EP_077e759A2_l_> 



EP 0 779 759 A2 

opaque pointer points can be used to implement the generic functions described below, tf this object typing is not fea- 
sible due to details of TIL encoding, the generic functions can be replaced with specific functions. 

TABLE 7 

ARCHITECTURE FOR TIL MANAGER MODULE 1403 
typedef char *opaque; 
typedef opaque Deck; 
typedef opaque Card; 
typedef opaque Text; 
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typedef opaque Entry; 

typedef opaque Option; 

typedef opaque SoftKey; 

typedef opaque Object; 

/* Generic functions */ 

FirstOpt ion (Object ob j , Option *o) ; 

/* obj is a card, softkey, entry, or deck */ 
GetSoftkey (Object obj. Option *o) ; 

/* obj is a card or deck */ 
Get Text (Object obj. Option *o) ; 

/* obj is a card or entry */ 

/* Deck functions */ 

SetDeck(Deck d, int length); 

/♦tells module which deck to use */ 
DeckGetCard(Card *c, int num) ; 

-or- 

DeckGetCard (Deck d, Card *c, int num); 

/* Card functions */ 

int CardType (Card c) ; 
CardFirstEntry (Card c, Entary *e) ; 
CardLookupSoftkey (Card c, int num, Softkey *s) ; 
CardlsLast (Card c) ; 



/* Option cursor functions */ 
OptionNext (Option *o) ; 
char *OptionKey (Option o) ; 
45 char *OptionValue (Option o) 

/* Entry cursor functions */ 

/* Text (and image) cursor functions */ 

so 

TextNextToken (Text *t, int *type, mt *subtype, 

int * length, char *data) ; 



55 



Archive manager module 1404 stores and retrieves long-lrved information. This information includes: data related 
to the server's location and/or required to support server scaling; data related to encryption; TIL caching (transparent 
to user); TIL storage (specified by user); and message storage and retrieval (see local manager module). Archive man- 
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ager module 1 404 shoukd support a variety of nonvolatile memory schemes that are provided by the two-way data com- 
munication device. 

Local manager module 1405 is an interlace to local device resources, such as local messages, address book 
entries, and preconfigured e-mail replies. Local manager module 1405 should also define an abstract interface to nav- 
igation manager module 1401 for use by archive manager module 1404. 

Table 8 is an architecture for an interface within local manager nxxJule 1405 to access to an address book stored 
on cellular telephone 700. The name of a routine in Table 8 is descriptive of the operations performed by the routine. 

TABLE 8 

ARCHITECTURE FOR ADDRESS BOOK ACCESS 
int NumAddresses ( ) ; 
char *AddressName (int num) ; 
char ♦AddressGetEMail (int nutn) ; 

// returns e-mail address 
char *AddressGet Phone (int nutn) ; 

// returns phone number 
char * AddressGetFax(int num) ; 

// returns fax number 
Set Address (int num, char *name, char *email, 

char *phone, char *fax) ; 
DeleteAddress (int num) ; 
InsertAddress (int before); 

Table 9 is an architecture for an interface unthin local manager module 1405 to access predetermined replies stored 
on cellular telephone 700. The name of a routine in Table 9 is descriptive of the operations performed by the routine. 

TABLE 9 

ARCHITECTURE FOR PRE- 
DETERMINED REPLY 
ACCESS 

int NumRepliesQ; 

char * GetReplypnt num); 

DeleteReply(irrt num); 

SetReply(int num, char *text); 

lnsertReply(int before); 



Table 10 is an architecture for an interface wrthin local manager module 1405 to access messages stored locally 
on cellular telephone 700. The name of a routine in Table 10 is descriptive of the operations perfomied by the routine. 
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TABLE 10 

ARCHITECTURE FOR LOCALLY STORED MESSAGE ACCESS 

5 

int NumMessages () ; 
void ♦FirstMessage { ) ; 
10 void *NextMessage ( ) ; 

int MessageType (void *msg) ; 

// e.g. e-mail, TIL, etc. 
void *MessageContent (void *msg) ; 

IS 

void *SaveMessage (int type, void *content, int 

contentLength) ; 
DeleteMessage (void *msg) ; 

20 



Event manager module 1 406 handles the distribution of events. In this embodiment, events include low-level events 
like key presses and higher level navigation and user interface events. There are typically only a small number of events 
25 at any one time. The main event loop in the two-way data communication device dependent module keeps calling 
EMjGelNexlEventO until no events are left in the queue. Note that processing one event can cause another event to 
be pushed onto the queue. The main event loop is not restarted until another event Is pushed onto the queue due to a 
user key press or a network event. 

In this embodiment, the event types include: 

30 

1} keypad events, i.e.. pressing of a key; 

2) choice events relating to a current choice card, e.g.. the user selecting choice three; 

3) text entry events relating to a current entry card. e.g., the user keying in ''Hello"; 

4) network events, e.g.. response arrived, request arrived, transaction terminated, network status; and 
35 5) history everns. e.g.. pap, pop to marker. 

Table 11 is an architecture for event manager module 1406. As in the other tables herein, the name of a routine in 
Table 1 1 is descriptive of the operations performed by the routine and in addition a brief description is given in the com- 
ment field. 

40 

TABLE 11 

ARCHITECTURE FOR EVENT MANAGER MODULE 1406 

45 

Struct Event { 
int type ; 
void *data; 

/* e*g. keycode, choice num, entry 
text, status code, other data */ 
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EM_QueueEvent ( int type, void * data) ; 

5 

/* Adds event at end of queue*/ 
EM_GetNextEvent (Event * event); 
/*Pops next event*/ 
10 EM_Pee3cNextEvent (Event event); 

/* Peeks at next event*/ 



15 Timer manager module 1407 allows timer events to support timeouts, animation, and other time<lomain features. 
Timeouts are delivered via event manager module 1406. 

Table 12 is an architecture for timer manager module 1407. As in the other taiales herein, the name of a routine in 
Table 12 is descriptive of the operations performed by the routine. 

^ TABLE 12 

ARCHITECTURE FOR TIMER MANAGER MODULE 1407 

25 Timer Init ( ) ; 

int TimerSetdnt milliseconds, int code, void 

*clientData) ; 
/♦Returns a timer identification timerld to 

30 

be used for cancellations*/ 
'^TimerCanceKint timerld); 
TimerCancelAll < ) 

35 



User interlace manager module 1408 handles Interactions with the keypad and the display. Each of the three types 
of user interfaces defined in Table 1 above requires a different version of user interface manager module 1408. For most 

40 cellular telephones, only one card at a time is used. However, some cellular telephones can display multiple cards at 
once and so would require a different version of user interface manager nrodule 1 408 from the version that handled dis- 
play of only one card at a time. 

In this errtxxliment. user interface manager module provides a user interface for the three types of cards display, 
choice, and entry; provides hooks for custom user interfaces for the address list and e-mail reply entry; only cares about 

45 the user interface aspects of cards and provides no navigation, argument, or option processing; handles all text arxl 
graphic layout including word wrapping; handles scrolling of text; operates from PIDL data structures; generates key- 
board events, some of which may be generated by soft keys; and generates high-level events. e.g. next card, choice 
entry 3, text entry "IBM". 

Table 13 is an architecture for processing cards by user Interface manager nxxlule 1408. As in the other tat»les 
so herein, the name of a routine in Table 13 Is descriptive of the operations performed by the routine. 
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TABLE 13 

ARCHITECTURE FOR CARD PROCESSING 
5 BY UI MANAGER MODULE 1408 

void UI_StartCard(Card c) ; 

/* called to begin display and processing of 
a given card*/ 
void UI_EndCard{Card c) ; 

/♦called when a card is no longer to be 
displayed*/ 
Boolean UI_HandleEvent {Event *pevent) ; 

/♦returns true if the event is handled, false 
20 if not*/ 



Table 14 is an architecture for the iser interface implementation by user interface manager module 1408. As in the 
25 other tables herein, the name of a routine in Table 14 is descriptive of the operations performed by the routine. 

TABLE 14 

ARCHITECTURE FOR UI IMPLEMENTATION 
BY UI MANAGER MODULE 1408 

UI_ Layout Card (Card c. Boolean draw, Proc 
35 callback) 

/* relies on global data; needs to be able 
to: draw as it goes; and note the 
special function of the currentLine 
(e,g, none, choice, sof tkey) */ 
int numLines, f irstVisible , lastVisible, 

currentLine ; 

char currentEntry [80] ; 
int currentChoice ; 
void *currentSof tkey; 
60 Card current Card; and 

. . . other info as needed for in-line 
scrolling 
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The callback routine is notified of the special function of each line as the line is laid out Thus, routine 
ULLayoutCard can be used to scroll to a particular chdce. If the current line ts too wide to display all at once, horizontal 
scrolling is used to display the complete line, one display width at a time. 
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Memory manager module 1409 is optional, and is used in two-way data communication devices that do not support 
dynamic memory allocation. In these devices, all memory allocation and releases must go through memory manager 
module 1409. Also, by allocating memory in advance via memory manager module 1409, client module 702 does not 
run out of memory due to some other process on the device using up memory. 

5 In one embodiment, the airnet network translator described above was used with an Internet server to communi- 

cate with client module. The Internet server was a UNIX computer running the Mosaic HTTP server. The executable 
code was generated by compiling the source code on a computer running the Sun Microsystems Operating System 
Solaris 2.4 using Sun Microsystems compiler SunPro C and C#. and the Sun Microsystems SDK make utility. Ail of 
these products are available from Sun Microsystems of Mountain View. California. 

10 Various embodiments of a novel interactive two-way data communication system, a two-way data communication 
device, an airnet networt^ architecture, and a predictive text entry system have been described herein. These embodi- 
ments are illustrative only of the principles of the invention and are not intended to limit the invention to the specific 
embodiments described. In view of this disclosure, those skilled in the art will be atiie to i«e the principles of this inven- 
tion in a wkje variety of applications to obtain the advantages of this invention, as described above. 
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APPENDIX I 
A DESCRIPTION OF PIDL AND TIL 
Unpublished ® 1995 Libris, Inc. 

The main structure of PIDL is described by an 
abstract syntax. This appendix describes the elements 
of the language and their semantics. In the syntax 
description of each element, an element is defined in 
an enhanced BNF. 



a : : = b 


the element a is defined as b 


a : : = b 
: : = C 


the element a is defined as b or c 


b C 


the element b followed by element c, the 
intervening space is just for clarity 


a|b|c 


element a or element b or element c 


{a} 


the element a is optional 


{a}* 


the element a may appear zero or more 
times in a row 


{a}* 


the element a may appear one or more 
times in a row 


abc 


the characters abc literally 


ol(a) 


an option list with zero or more topions 
of the element a, see Options below 



In general, the element blank-space can optionally 
appear between any two other elements. To keep the 
diagram clear, it has been omitted except where 
required. Where a blank- space is illegal or treated 
specially, it is noted. 
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deck 

deck -header 
deck-options 
deck- footer 



15 



20 

o-cost 

25 O-ttl 
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The PIDL ELEMENTS 

::= deck-header {softkey}* {card}+ deck- 
footer 

<PIDL ol (deck -options) > 
::= o-args | o-cost | o-ttl 

: := </PIDL> 

A deck consists of one or more cards. 
There must be at least one card. A deck 
may also have a number of softkeys 
defined that stay in force for the whole 
deck. See soft keys below for the 
syntax and full description. 

: : = costs value 
: : = ttlss integer 

Additional arguments to be passed on the 
next deck rec[uest are given in o-args. 
See Arguments below for syntax and full 
description. 

The cost of retrieving this page 
(exclusive of telephone system charges) 
is represented in o-cost. If no o-cost 
is given, the deck cost is included with 
the user's standard service contract. 

Decks can be cached by the cellular 
telephone for a period of time. The o- 
ttl entry indicates the number of 
seconds that the deck can be cached from 
time of reception. If no o-ttl entry is 
given, the deck can only be cached for 
short periods of time, for example, to 
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implement a back function similar to 
that of most Web browsers. If the value 
of o-ttl is zero, the deck must not be 
cached , 



70 
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CARD ELEMENTS 
card : := display-card | choice card | entry- 
card 

A card is one of three types of card in 
this embodiment . These are described in 
the sections below. 



20 
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card-options 
o-name 
o-next 
o-prev 



= o-name | o-next | o-prev 
= names identifier 
= nexts destination 
= preva destination 
All cards can have these options. The 
optional o-name option gives a name to 
the card. If a card has a name, the 
card Ccui be referred to by a 
destination. 
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40 



45 



so 



The o-next and o-prev give destinations 
for the NEXT auid PREV keys. If omitted, 
the defaults are the next and previous 
sequential card in the deck. If o-prev 
is omitted from the first card, the PREV 
key returns to the deck last visited. 
If o-next is omitted from the last card, 
the NEXT key returns to the first card 
of the current deck. However, this 
default behavior is only a fail-safe: 
the last card in a deck should always 
have either an o-next option, or be a 
choice card where each choice entry 
indicates a new destination. 
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DISPLAY CARD 



70 
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20 



display-card 

display-header 
display- opt ions 
display- cent ent 

display- footer 



::= display- header display-content 
display- footer 

= <DISPliAY option-list > 
= card-options 

= { softkey }* formatted text 
= </DISPLAY> 
Display cards give information for the 
user to read. See Formatted Text below 
for a full description of the format of 
information that can be displayed, 
Softkeys can be described for this card 
only, see Softkeys below. 
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choice-card 

choice-header 
choice -options 

o -method 
method -type 
entries 

choice - footer 



50 



CHOICE CARD 
::= choice-header display-content 
{ entries } choice -footer 
::= <CHOICS ol { choice -opt ions } > 
::= card-options | o-method | o-key 
I o-default 

methods method-type 

nxunber | list | alpha | group 
::= { choice-entry }+ 

::= { group-entry { choice-entry }+ )+ 
: := </CHOICE> 

Choices let user pick one from a list. 
The initial display content is shown to 
the user, followed by the choices. Each 
choice can have one line of formatted 
text (which may be wrapped or scrolled 
by the phone if too long) . 



How the choices are displayed and chosen 
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is based on the o-method option. Note 
that this option is a hint only, and can 
be disregarded by the phone. The number 
method is the default and indicates that 
the choices are numbered sequentially 
from one and are chosen by pressing the 
appropriate digit on the keypad. If 
there are more than nine options, the 
phone may choose some other method of 
15 selection. The list method indicates 

that the list should be unnumbered and 
that the user should scroll through the 
list and hit some designated enter key 
to choose an entry. The alpha method is 
like list, only it is an indication that 
the text of the entries should be used 
to aid selection if at all possible. In 
this case, the entries are assumed to be 
alphabetically sorted. The group method 
is described in more detail below. 
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The o-key option indicates, if present, 
the key of an argument to be added to 
the argument list. See Arguments below 
for more information. The value of the 
argument comes from the choice entry; 
see below. The o-default option 
indicates the default value if the user 
just hit ENTER. See o-default under 
Entry Card below for more information. 



choice-entry <CE ol (entry-options) > 

formatted- line 
so entry-options ::= act ion- opt ions | o-value 

Each choice has text displayed to the 
user. If the action-options are given, 

55 
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the indicated action is performed if the 
choice is made. if the o-value option 
is present, it supplies the value to the 
argument identified with the o-key 
option in the choice header. If no o- 
value is given, the text of the entry is 
used (without any formatting) as the 
argument value. 



15 



group -entry 
group - opt ions 
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<GE ol (group -opt ions ) > 
: : = labels value 

If the group method is used, the choices 
are divided into a number of groups . 
Each group is headed by a group -entry, 
which, via the label option, gives a 
short name to the group. The phone can 
then give the user a hierarchial 
interface for choosing among a large 
number of choices. The text of the 
label should be limited to eight 
characters and may be truncated by the 
phone . 



ENTRY CARD 

entry-card ::= entry-header display-content entry- 
footer 

::= <ENTRY ol (entry-options) > 
::= card-options ( o-format | o-key 

I o-default 
: : = </ENTRy> 

Entries let the user enter a value. The 
display content is shown to the user, 
followed by an entry line. The user's 
entry is controlled by the format . The 
o-key option indicates the argument that 



entry-header 
entry- opt ions 

entry- footer 
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is being set by this entry. The value 
of the argument are the user's entry. 

o-format formats value { ; format-hint } 

format -hint ::= value 

This option specifies the format for 
user input entries- The string consists 
of format control characters and static 
text which is displayed in the input 
area. Most of the format control 
characters control what data is expected 
to be keyed in by the user. They are 
displayed as blanks tmtil the user types 
into them. 

The format codes are : 

A entry of any alphabetic 

character 
9 entry of any numeric character 
X entry of any alphabetic or 

numeric character 
*f allow entry of any number of 

characters; the next character, 
f , is one of A, 9 or X and 
specifies what kind of 
characters can be entered. 
\c display the next character, c, 
in the entry field; allows 
display of the formatting 
characters in the entry field. 

Format hints indicate what kind of value 
is expected. If a format hint is not 
understood, it is ignored. Currently 
defined format hints are: 
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20 

o-def ault 

25 
30 

formatted- text 

formatted- line 
35 text -line 

40 

text -format 

45 



50 
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text text is expected to be 

text, use special 
input techniques; 
generally follows *A 
or ♦X 

mail -reply like text, but 

expected text is for 
an e-mail message or 
page; may affect input 
algorithm 

address- list entry is a list of 
e-mail addresses 

defaults value 
The o-default option supplies a value 
that is used if the user simply hits 
NEXT. If no default value is given, 
then the user must supply a value . 

FORMATTED TEXT 

::= { { flow- image } { line- format } 
text -line )* 
: : = text-line 

::= { text I image | text -format | 
alignment -format }* 

Formatted text is what is shown to the 
user in most cards. Formatted lines are 
used for choice entries . 

: : = <B> I <I> I <BL> 
; := </B> I <I> I <BI.> 

The format codes control Bold, Italic 
and Blinking, The slash versions cancel 
the formatting. Unlike HTML, these 
needn't be strictly nested and over 
application and over cancellation are 
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15 



tolerated. Formatted- text and 
formatted-line elements start in plain 
mode (no bold, italic, or blinking) . 

alignment -format <CENTER> | <BOI<D> | <TAB> 

The alignment codes specify how parts of 
a line are to be laid out . The text 
following the alignment code is either 
centered or right justified on the same 
line as the other text. The text or 
image following the code is considered 
to be all text up to the next alignment 
code or line break. All lines start 
^ implicitly aligned left. Note that 

these do not include am implicit line 
break so that one can have both left and 
right justified text on a single line. 
If there is too much text and not enough 
room on the line then, if in wrap mode, 
the non- fitting text is moved to the 
30 next line and aligned the same way. If 

in line mode, the line may end up 
running together with two spaces between 
the left, center, and right justified 
segments . 



25 



35 



The tab code is used to create aligned 
columns. Rather thoin tab to specific 
character positions, the tab code 
separates the text for each column. The 
width of the column is determined by the 
maximal width of the text (or images) in 
each line. The extent of the columns is 
from the first line with tab codes 
so through the last contiguous line with 

tab codes. Some lines may have fewer 
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tab codes than others, in which case 
they are assumed to have no text for the 
extra columns . 



line -format 
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: := <WRAP> | <LINE> 
: := <BR> 

Multiple lines of text are separated by 
the <BR> code. If a line is too long to 
fit on the screen and, if in wrap mode, 
the line is word wrapped onto multiple 
lines. If in line mode, the line is 
left as one line and is scrolled 
horizontally. Format ted- text and 
formatted- line elements start in wrap 
mode and may be changed with either the 
<WRAP> or <LINE> codes. These codes are 
an implicit line break. 
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image 



flow- image 



image - opt ions 
flow- image - opt ions 
inline-data 



IMAGES 

I- <XMA6E ol (image -options) > 
:= <INLXNE ol (image -options) > 
inl ine - dat a < /ZMLINE> 
:= <XMA6E ol (flow- image -opt ions) > 
:= <XKI«XKE ol (flow- image -options) > 
inline-data </IllLXNE> 
= o- source 

= image -opt ions | o-flow 
= ASCIIS 5 encoding of Image data 
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Images are treated as large words and, 
by default, are simply displayed as part 
of the text. Flow- Images have a flow 
option that causes them to be treated 
differently. The image data is stored 
in a separate data stream as identified 
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by the source option. 

Inline images are treated identically, 
only the data is part of the current 
data stream. ASCII85 is a standard way 
of encoding binary data in printable 
ASCII, whereby each four bytes of data 
is encoded in five characters. Note 
that TIL only uses inline images, and 
uses a different encoding, 

o- source : :« 0rc» location 

This option specifies the location of 
the source for images . 

o-flow ::= flow- { loft 1 right } 

This option controls the alignment of 
flow- images. The option specifies that 
the image is flush left or flush right 
with the screen. Subsequent lines of 
text flow in the remaining right or left 
hand space. 

SOFTKEYS 

softkey : := <SOFTKEY ol ( sof tkey-opt ions ) > 
sof tkey-options : := o-label | o-button | act ion- opt ions 

Softkeys supply definitions for two 
buttons known as SOFT-L and SOFT-R. 
They do not show up in the normal text 
and graphics area displayed to the user, 
but on a separate line for soft key 
labels. (Note: in some implementations, 
where screen real estate is scarce, this 
label line may get used for normal text 
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and graphics display when there are no 
softkeys defined on the current card) . 

When the softkey is pressed, the 
indicated action takes place. 

button ::= buttons side 
side : := left | right 

-label ::= label» value 

The button option specifies which 
physical key the softkey applies to. 
The label option is the text that is 
displayed on screen for that key. The 
phone may truncate the label. It is 
suggested that labels be fewer than 
eight characters. 

Softkeys can be specified both for the 
deck as a whole and per card. When 
specified for the deck (after the deck- 
header, but before the first card) they 
remain in effect for the entire deck. 
When specified for a card (at the 
beginning of the formatted- text for the 
card) , they temporarily override any 
deck softkeys while the card is visible. 
Note that the override is done 
independently for the two keys (a card 
can override one softkey, but not the 
other) . To override a deck softkey with 
no softkey (in effect, to remove a 
softkey for the duration of a card) use 
a softkey with no label and no action. 

SYNTAX: OPTIONS 
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ol (valid-option) 

option-list 
option 
key 
value 



Many of the syntactic elements of PIDL 
have option lists associated with them. 
Options refine the operation of the 
elements they are part of. Unless 
otherwise noted, options do not nest, 
even when the same option is given in 
two nested elements. Options that are 
not defined for an element are ignored, 
even if valid for an enclosing element. 



::= { blank-space valid-option }* 
{blank-spaces } 
= ol (option) 
= key = value 
= identifier 
= plain-text 
= " { text } " 
An option list contains zero or more 
options. Each option is separated by 
blank-space (requiredl) and optionally 
followed by blank-space. In the syntax 
diagrams, option lists are shown as: 
oKvalid'option) where vstl id- option is 
replaced with an element that defines 
the possible options in this context, 
ol is a generic syntactic description of 
option-lists. 
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Each option is a key and a value. They 
may be given in any order within the 
list of options. The key is always an 
alpha-numeric name that is case 
insensitive. The value, if it is 
composed of only alphanumeric 
characters, may appear directly after 
the equals sign. Othearwise, the value 
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must be quoted. In quotes, blank-space 
is treated literally and is considered 
part of the value. 

In the syntax diagrams, the possible 
values for various options are specified 
without quotes. However, quotes are 
always acceptable around an option 
value - 

Unlike almost all other syntactic 
elements, blank space is not permitted 
between the key and the equals sign or 
between the equals sign and the value. 

Many options have a more restricted set 
of possible values than represented by 
the cQxjve syntax. See the individual 
options for details • 



destination 



DESTINATIONS 

= location { ; animation } 
= card-loc { ; cinimation } 
= stack-operation { ; animation } 



location ::= full-loc | partial-loc 



full-loc 



partial-loc 



1 relative -loc 

= : service- id / deck-path 
= : service-host / deck-path 
= / deck-path 



relative-loc { ../ }* deck-path 



card-loc ::= # identifier 



deck-path 
service- id 



:= plain-text { / plain- text }* 
:= % plain- text 
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service-host : := plain- text 

Destinations are used in some options to 
indicate the next, or previous deck or 
card to show. A deck is specified 
either with a full location (service-id 
and deck-path) , just a deck-path (in 
which case the service is the same as 
the current deck's service), or a 
relative deck-path. In the later case, 
the last component of the current deck- 
path is removed, (and one additional 
component for each . , / in the relative 
deck-path) , and the deck-path appended. 

A particular card can be a destination 
and is specified by a card-loc element. 

stack-operation : := + card-loc 

In addition to the normal history list 
of where a user has been that is kept by 
a phone, the phone also keeps a short 
stack of locations. Using a plus sign 
form causes the current location (deck 
and card,, and location in the history 
list, and animation used) to be pushed 
on the stack before going to the new 
card. Using the minus sign form causes 
a return to the location on the top of 
the stack, cmd the history list to be 
pruned back to the saved point. If no 
animation is given, the inverse 
animation is used. The stack is popped. 

animation : i- slldeN | slideS 
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: : = slideW | slideE 
: : = slideSW | slideNE 
::= slideSE | slideNW 
: : = f llpV 
: : = f lipH 
: : fade 
: : « none 

The optional animation argument 
indicates what form of screen animation, 
if available, is to be used when going 
to the destination. The animation is 
remembered with the destination in the 
history and destination stack. If the 
user moves to a destination via a 'go' 
or 'next' operation, then the animation 
is performed. If the user moves to a 
destination via a 'prev' or 'pop' 
operation, the reverse animation 
associated with the current location is 
performed. 

ACTIONS 

Choice entries and soft keys can specify 

actions to be performed when the user 

selects the choice or softkey. 

action-options o-args | o-call 

I o-page 
o-go : := go« destination 
call : : = calls value 

The go operation indicates that the 

destination should be moved. 

ARGUMENT PROCESSING 

Each time a deck is requested, arguments 
may be passed along with the request. 
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These arguments may be used by the 
service end to compute a deck specific 
for the user rather than just return a 
pre-written deck. 
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Arguments are built-up as the user 
traverses the deck. Each argument is a 
key- value pair. While arguments 
superficially look like options^ these 
two entities are quite distinct: Options 
are a part of PIDL and affect the 
operation of the phone. Arguments are 
information gathered by the phone and 
returned to the service . Neither PIDL 
nor the phone understands the arguments 
beyond their basic syntactic structure. 

Arguments come from three places : Choice 
cards. Entry cards, and the args option. 
Each of these specifies a key-value pair 
that is added to a buffer of arguments 
to be sent. In the case of the args 
option, multiple arguments may be 
specified. When an argument key- value 
pair is added to the argument buffer, if 
the key is already present in the 
buffer, its value is replaced. 
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o-args 
argument -list 

arg-key- value 
arg-key 
arg-value 



::= argss arg-list 

: := arg-key- value { { & 

key- value }* 

= arg-key = arg-value 
= identifier 
= plain- text 



Note: The entire o-args element is 



55 



53 

JSDOCID: <EP_0779759A2_L> 



EP0779 759A2 



10 



o-key 
o -value 



15 



20 



actually the value of an option. If it 
has more than one arg-key-value it will 
need to be in quotes. Since the 
ampersand {&) and semi-colon (;) are 
used as key- value pair separators, these 
characters cannot be part of argument 
values . 

: := keys arg-key 
: := values arg- value 

These options are used in choice and 
entry cards to specify the key and value 
for the arguments those cards set . 
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alpha 
numeric 
a Ipha - nume r i c 
hex 

blank- space 
space 
tab 
new- line 



BASIC ELEMENTS 

= any alphahetic character 
= any digit 
= alpha I numeric 

= numeric | any letter A through F, 
either case 

~ { space I tab | new- line }+ 
= the space character 
= the tab character 
= the carriage return character 
= the line feed character 
= the sequence carriage return, line 
feed 
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word 
identifier 
integer 

text 



- { alpha-numeric }+ 

= alpha { alpha-numeric }* 

= { + I - } { numeric }+ 



: := any 7 -bit ASCII character except <, 
>/ or & 

> | < | " | &sunp; 
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plain-text 



I &zibsp; 

any ISO-Latin-l named entity 
: : = &# hex hex ; 

In text, runs of blank-space are treated 
as single spaces and my be used as point 
for word wrapping. 
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safe { alpha | numeric | safe }* 

$ I - I _ 1 ® I • I & 



I 



TIL ENCODING 



Except where noted, TIL is identical to 
PIDL in structure. To translate PIDL to 
TIL several steps are conceptually 
25 needed (these may be done in one pass by 

a translator) : 



1, Escape characters with the high 
bit set . 

2, Compress or remove all blank space 
where possible - 

35 3- Tokenize comment elements with a 

single byte with the high bit set. 
4 . Inline images . 

40 

Fundamentally, TIL is just PIDL with 
certain common character sequences 
replaced by single bytes with the 
45 high-bit set. The first two steps above 

support this. Additionally, images are 
further compacted by including them 
inline in a dense format. 



The tokenizing follows the encoding 
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given in the table below. Note that for 
purposes of element separation, the 
tokens that represent option key- 
identifiers (with the equal sign) can be 
considered to include all preceding 
blank space. Similarly, the tokens that 
represent option values can be 
considered to include all following 
blank space. 
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<PIDL> 


90 


args= 


CO 


alpha 


EO 


5 


</PIDL> 


91 


button= 


CI 


center 


El 




<DISPIiAY> 


92 


call= 


C2 


fade 


E2 


10 


</DISPLAY> 


93 


costs 


C3 


f lipH 


E3 




<CHOICE> 


94 


def ault:= 


C4 


flipV 


E4 




</CHOICE> 


95 


f low= 


C5 


group 


E5 


15 


<ENTRY> 


96 


f ormat= 


C6 


inline 


E6 




</ENTRy> 


97 


go= 


C7 


left 


E7 


SO 


<CE 


AO 


keya 


C8 


list 


E8 




<GE 


Al 


labels 


C9 


none 


E9 


25 


< IMAGE 


A2 


method= 


CA 


number 


EA 




< INLINE 


A3 


names 


CB 


right 


EE 




<SOFTKEY 


A4 


next = 


CC 


slideE 


EC 


30 


<B> 


BO 


pages 


CD 


slideN 


ED 




</B> 


Bl 


prev= 


CE 


slideNE 


EE 


35 


<I> 


B2 


arcs 


CF 


slideNW 


EF 




</I> 


B3 


ttl= 


DO 


slides 


FO 


40 


<BL> 


B4 


values 


Dl 


slideSE 


Fl 


</BL> 


B5 






slideSW 


F2 




<CENTER> 


B6 






slideW 


F3 


45 


<RIGHT> 


BY 












<WRAP> 


B8 










SO 


<LINE> 


B9 












<BR> 


BA 
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APPENDIX II 
A COMPUTER PROGRAM TO GENERATE 
A LETTER FREQUENCY TABLE 
FOR USE IN THE PREDICTIVE DATA ENTRY PROCESS 
Unpublished ® 1995 Libris, Inc. 

This program opens a text file selected by the 
user, generates the frequency table for that file, 
and then writes the frequency table to another 
file also selected by the user. 



7 



#include <stdio.h> 
#include <string,h> 
#include <console . h> 
#include <assert . h> 



typedef unsignied char byte; 

typedef byte triplet [3]; 

typedef byte tristorage [27] [27] [27] ; 

IncrementTrigram( triplet t, tristorage trigrams) 

{ 

byte * pb; 
assert (t[0] < 27) 
assert (t[l] < 27) 
assert (t [2] < 27) 

pb = &trigrams [t [O] ] [t [1] ] [t [2] ] ; 
if (*pb < 255) *pb = *pb + 1; 
return *pb; 



} 



StoreTrigramValue (triplet t, tristorage trigrams, byte 
value) 

{ 
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assert (t [O] < 27) ; 
assert (t [1] < 27) ; 
assert (t [2] < 27) ; 

trigrams (t [O] ] [t [1] 1 [t 12] ] = value; 

} 

byte FetchTrigramvalue (triplet t, tristorage trigrams) 
{ 

assert (t [O] < 27) ; . 
assert (t [1] < 27) ; 
assert (t [2] < 27); 

return trigrams [t [O] ] [t [1] ] (t [2] ] ; 



byte DumpTrigram{ triplet t, tristorage trigrams) 

{ 

byte value; 
assert (t [O] < 27) ; 
assert (t [1] < 27) ; 
assert (t [2] < 27) ; 

value = FetchTrigramvalue (t, trigrams); 

if (value O) 

{ 

printf ("%c%c%c = t [O] + 'a', t [11 + 'a', t[2) 

' a ' ) ; 

if (value == 255) printf ("***") ; 
else printf ("%3d'' , value); 

} 

return value; 

} 

int IdFromChar (short c) 

{ 

c =5 tolower(c) ; 

if (c< 'a' II c>'z') return 26; 
return c - 'a' ; 
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} 

AddChar (tristorage trigrams, triplet t, byte b) 

{ 

byte value; 
unsigned short re- 



assert (b <- 26) ; 
if (b ~ 26) { t[0] 

t [0] = t[l] ; 
t [1] = t[2] ; 
t[2] = b; 



- t[l] = tt2] = 26; return; 



value FetchTrigramValue (t , trigrams) ; 
if (value == 255) return; 

#if 0 

if (value > 64) { 
r = Random () ; 

if (value > 192 && r & OxEOOO) return; 
else if (value > 128 && r & OxCOOO) return; 
else if (value > 64 && r & 0x8000) return; 

} 

#endif 

StoreTrigramValue (t, trigrams, value +1); 

} 

DumpTrigrams (tristorage trigrams) 
{ 

int i, j, k; 
int X; 
triplet t; 
X = O; 

for (i = 0; i < 26; ++i) 
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for (j = 0; j < 26; ++ j ) 
for (k = 0; k < 26; ++k) 

{ 

byte value; 
t[0] = i; 
t[l] = j; 
t[2] = k; 



value = DumpTr igram ( t , crigrams) ; 

if (value == 0) continue; 
if (++X ==6) { 

printf ("\n") ; x = 0; 

} 

else 

printf ( " ") ; 

} 

) 

OSErr BuildTrigram( short refNum, tristorage trigrams) 
{ 

OSErr err; 
triplet t; 

t[0] = t[l] = t[2] = 26; 
while (true) 

{ 

long count = 80; 
char buf [80] ; 
int i ; 

err = FSRead(refNum, &count, buf); 
if (count == 0) return err; 
for (i = 0; i < count; ++i) { 

AddChar ( trigrams , t , IdFromChar (buf [i] ) ) ; 
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} 

if (err) return err; 

} 

return 0; 

} 

Handle OpenTrigrams (void) 

{ 

OSErr err; 
OSType type; 
StandardFileReply reply 
short refNurti; 
short id; 
Hajidle h; 
Str63 name; 
tristorage *trigrams ; 

type = 'TEXT' ; 

StandardGetFile (nil, 1, &type, &reply) ; 
if (! reply. sf Good) return nil; 

err = FSpOpenDF (&reply . sf File, fsCurPerm, &refNum) ; 
if (err) return nil; 

memcpy (name, reply . sf File .name, sizeof (name) ) ; 
h = NewHandle (sizeof (tristorage) ) ; 

HLock(h); 

trigrams = (tristorage *) (*h) ; 

memset (*trigrams, 0, sizeof (tristorage) ) ; 

BuildTrigram(refNum, *trigrams) ; 
FSClose (refNum) ; 
DumpTrigrams (* trigrams) ; 
HUnlock(h) ; 
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type = ' rsrc ' ; 

StandardGet File (nil, 1, &type, &reply) ; 
if ( ! reply . sf Good) return ; 

refNum - FSpOpenResFile (&reply . sf File, f sCurPerm) ; 
if (refNum == -1) return; 
UseResFile (refNum) ; 

id = UniquellD (' smrt ' ) ; 
//id = 128; 

AddResource (h, 'smrt', id, name); 
UpdateResFile (refNum) ; 
FSClose (refNum) ; 
return h; 

) 

mainO 

{ 

OSErr err; 
Handle h; 

cshow(stdout) ; 
TEInit ( ) ; 
InitDialogs (OL) ; 
InitCursor () ; 
h = OpenTrlgrams ( ) ; 



Claims 

1 . A two-way data communication system for communication between a computer and a two-way data communication 
device selected from a group consisting of a cellular telephone (105), a two-way pager (106). and a telephone 
(107), said two-way data communication system comprising: 

a two-way data communication network (1 1 0, 1 1 1 , or 1 1 2) ; 
a server computer comprising: 

a two-way data communication interface module (748) coupled to said two-way data communication net- 
work: and 

a server (121 , 131. or 141) coupled to said two-way data communication interface module: 

wherein said server (121,131.or141] receives a message including a resource locator from said two- 
way data communication network, and said resource locator includes an address of said server (1 21 . 
131, or 141): 
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said server (121. 131. or 141) processes said message using said resource locator; and 
said server (121 , 131. or 141) transmits a response to said message over said two-way data commu- 
nication network(110. Ill, or 112); 

5 a two-way data communication device ( 1 05. 1 06. or 1 07) coupled to said two-way data communication network 

(1 10. 1 1 1. or 1 12) wherein said two-way data communication device (105, 106. or 107) is selected from the 
group consisting of a cellular telephone (105). a two-way pager (106). and a telephone (107), and further 
wherein said two-way data communication device (105, 106. or 107) further comprises: 

^0 a network interface module (71 4) coupled to said two-way data communication network: and 

a client module (702) coupled to said network interface nrxxlule (704); 

wherein said client module transmits said message including said resource locator to said server (121 . 
131. or 141) over said two-way data communication network; and 
'5 said client module processes said response to said message from said server (121. 131, or 141) 

wherein sakJ response includes information for user Interaction over said two-way data communica- 
tion network (110. 111. or 112). 

2. A two-way data communication system for communication between a server computer and a cellular telephone. 
20 said two-way data communication system comprising: 

a data capat>le cellular telephone communication network (110); 
a server computer comprising: 

25 a two-way data communication interface module (748) coupled to said data capable cellular telephone 

communication network (1 10); and 

a sender (121 . 131 . 141) coupled to said two-way data communication interface module; 

wherein said server (121, 131. 141) receives a message including a resource locator from said data 
30 capable cellular telephone communication network (110), and said resource locator includes an 

address of said server (121, 131, or 141); 

said server (121. 131. or 141) processes said message using said resource locator; and 

said server (121. 131 . or 141) transmits a response to said message over said data capable cellular 

telephone communication network; 

35 

a cellular telephone device (1 05) coupled to said data capable cellular telephone communication network (1 1 0) 
wherein said cellular telephone device (105) further comprises: 

a network interlace module (714) coMpled to said data capable cellular telephone communication network 
40 (110); and 

a client nrxxJule (702) coupled to said network interface module (714); 

wherein said client module transmits said message including said resource locator to said server (121. 
131. or 141) over said data capable cellular telephone communication network (1 10); and 
45 said client module processes said response to said message from said server (121. 131, or 141) 

wherein said response includes Information for user interaction over said data capable cellular tele- 
phone communication network (110). 

3. A two-way data communication system as in Claims 1 and 2 wherein said client module further comprises an inter- 
so prefer wherein said interpreter generates a user interface using information in said response, and said user inter- 
face includes at least one user data input option associated with a resource locator. 

4. A two-way data communication system as in Claim 3 wherein said resource locator associated with said at least 
one user data input option addresses an ok>ject on said server computer. 

55 

5. A two-way data communication system as in Claim 3 wherein said resource locator associated with said at least 
one user data input option addresses an object on another server computer coupled to said communication net- 
work 
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6. A two-way data communication system as in Claim 3. 4 or 5 wherein said interpreter includes a plurality of manag- 
ers including a user interface manager coupled to a display of said device wherein said user Interface manager 
handles interactions with said display 

7. A two-way data communication system as in Claim 7 wherein said user interface manager is coupled to a keypad 
of said device and further wherein said user interface manager handles interactions with said keypad. 

8. A two-way data communication system as in Claim 7 wherein said another resource locator including said address 
of said sender (121 . 131 , or 141) and said input data comprises a uniform resource locator 

9. A two-way data communication system as in any preceding Claim wherein said response inclides a plurality of 
resource locators and at least one of said plurality of resource locators includes an address to another server (121 , 
131, or 141) coupled to said communication network. 

1 0. A two-way data communication system as in any preceding Claim wherein said server (121 , 1 31 . or 141) is a state- 
less server and upon said server (121. 131, or 141) completing transmission of said response, said server (121, 
131 . or 141) completes all processing of said request and retains no state information for said response. 

11. A two-way data communication system as In any preceding Claim wherein upon said server (121 , 131 . 141) com- 
pleting transmission of said response, said server (121, 131. 141) maintains state irtformation concerning said 
message wherein said server (121 . 131 . 141) utilizes said state information concerning said message In response 
to another message from said device. 

1 2. A two-way data communication system as In any preceding Claim wherein said device further comprises: 

a memory (716); and 

a resource locator stored in said memory. 

1 3. A two-way data communication system as in any preceding Claim wherein said server computer further corrprises: 

a memory (755); and 

at least one common gateway interface program (761) stored in said memory 

1 4. A two-way data communication system as in any preceding Claim wherein said server computer further connprises: 

a memory (755); and 

at least one card deck stored in said memory. 

1 5. A two-way data communication system as in any preceding Claim wherein said device further comprises: 

a keypad (715) having a plurality of keys; arKi 

a keypad module (711) coupled to said keypad (715) and to said client module (702) 

wherein upon a user pressing a key in said plurality of keys, said keypad module stores information iden- 
tifying the pressed key in a buffer memory; and 
said keypad module notifies said client module of said key press. 

16. A two-way data communication system as in Claim 16 wherein said client module (702) further comprises a pre- 
dictive data entry module (901 ), wherein said client module uses said predictive data entry nnodule to process said 
stored information identifying the pressed key upon said client module receiving said notification of said key press. 

17. A two-way data communication system as in Claim 16 wherein said predictive text entry module (901) generates a 
table index using at least one character in said buffer memory of said device in combination with information char- 
acterizing said key pressed by said user: and said predictive text entry module retrieves at least one predictive 
character entry from a table of predictive character entries stored in a memory using said table Index wherein said 
at least one predictive character entry represents a character in a plurality of characters represented by said 
pressed key. 

18. A two-way data communication system as in Claim 1 7 wherein sad at l^st one character in said buffer memory is 
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included in a plurality of characters in said memory buffer and further wherein said plurality of characters are used 
in generating said table index. 

1 9. A two-way data communication system as in Claim 1 8 wherein each character in said plurality of characters in said 
5 memory buffer is a character in a set of characters and further wherein 

each character in said set of characters is represented by a unique nunrtier and said unique numbers range 
from 0 to (N-1) where N is a number of characters in said set. 

20. A two-way data communication system as in Claim 1 9 wherein said plurality of keys comprises M keys where M is 
10 an integer. 

21. A two-way data communication system as in any preceding Claim wherein said device further comprises: 

a card deck stored in a memory of said device. 

IS 

22. A two-way data communication system as in Claims 14 and 21 wherein said card deck includes a display card, or 
a choice card or an entry card. 

23. A two-way data communication system as In any preceding Claim wherein said device further comprises: 

so 

a display (705); and 

a display module (712) coupled to said display and to said client nrodule (702) wherein said display OKXiule 
drives said display in response to user Interface information from said client nxxiule. 

25 24, A tNvo-ray data communication system as in any preceding Claim wherein said two-way data communication 
device ts said cellular telephone or said two-way pager or said telephone. 

25. A method for using a two-way data communication device, selected from a group consisting of a cellular telephone, 
a two-way pager, and a telephone, to communicate with a server computer corrprising: 

30 

generating a message by a client module in response to data entered by said user of a two-way data commu- 
nication device coupled to a two-way data communication networK 

wherein said client nKKlule executes on a microcontroller of said two-way data communication device; 
35 said message includes a resource locator; and 

said two-way data communication device Is selected from a group consisting of a cellular telephone, a two- 
way pager, and a telephone 

transmitting said message over said tvw>-way data communication network to a server computer wherein said 
40 server computer is identified by said resource locator; 

executing an application on said server computer iderrtified by said resource locator to generate a response to 
said message: and 

transmitting said response to a location identified by said application. 

45 26. A method for using a two-way data communication device, selected from a group consisting of a cellular telephone, 
a two-way pager, and a telephone, to communicate with a server computer, as in Claim 25 wherein said response 
is transmitted to said client module. 

27. A method for using a two-way data communication device, selected from a group consisting of a cellular telephone. 
50 a two-way pager, and a telephone, to communicate with a server computer, as in Claim 26 further comprising: 

interpreting said response by said client module and generating a user Interface using information in said 
response wherein said Interface includes at least one user data input option associated with a resource locator. 

55 2a A method for using a two-way data communication device, selected from a group consisting of a cellular telephone, 
a two-way pager, and a telephone, to communicate with a server computer, as in Claim 27 wherein said resource 
locator associated with said user data Input option addresses an object on said server computer. 

29. A method for using a two-way data communication device, selected from a group consisting of a cellular telephone. 
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a two-way pager, and a telephone, to communicate with a server computer, as in Claim 28 wherein said resource 
locator associated with said user data input option addresses an object on another server computer. 

30. A method for using a two-way data communication device, selected from a group consisting of a cellular telephone. 
5 a two-way pager, and a telephone, to communicate with a server computer, as in Claim 29 further comprising: 

interpreting a data input entry by a user of said two-way data communication device. 

31 . A nnethod for using a two-way data communication device, selected from a group consisting of a cellular telephone. 
10 a two-way pager, and a telephone, to communicate with a server computer, as in Claim 30 further comprising: 

appending said data input entry to said resource locator associated with said data input entry option. 

32. A method for using a two-way data communication device, selected from a group consisting of a cellular telephone, 
75 a two-way pager, and a telephone, to communicate with a server computer, as in Claim 25 wherein satd response 

is a card deck and further wherein said card deck includes at least one card. 

33. A method for using a two-way data communication device, selected from a group consisting of a cellular telephone, 
a two-way pager, and a telephone, to communicate with a server conputer, as in Claim 25 further comprising: 

20 

Storing said card deck stored in a memory of two-way communication device. 

34. A method for using a two-way data comnrujnication device, selected from a group consisting of a cellular telephone, 
a two-way pager, and a telephone, to communicate with a server computer, as in Claim 33 further comprising: 

25 

processing said stored card deck using said client nrxxiule. 

35. A method for using a two-way data communication device, selected from a group consisting of a cellular telephone, 
a two-way pager, and a telephone, to communicate with a server computer, as in Claim 34 further comprising: 

30 

generating a display on two-way data communication device for each card in saU card deck. 

36. A two-way data communication device having a microcontroller, wherein said two-way data communication device 
comprises: 

35 

a memory; 
a display; 

a display module coupled to said display wherein said display module drives said display; 
a keypad including a plurality of keys; 
40 a keypad module coupled to said keypad 

wherein upon a user pressing a key in said plurality of keys, said keypad module stores information 
identifying the pressed key in said memory; 

a network interface module wherein said network interface module receives data from and sends data to a two- 
way data communication network; 
45 a client module coupled to said display module, said network interface module, said keypad module, and said 

memory; 

wherein said client module executes on said microcontroller; 

said client module, in response to a signal from said keypad module, processes said stored infornration 
so identifying the pressed key and stores a character in a memory buffer; and 

upon completion of data entry, said client module retrieves all characters in said memory buffer and gen- 
erates a request including said characters to said network interface module which in turn transmits said 
request including said characters over said two-way data communication network. 

55 37. A two-way data communication device as in Claim 36 further conrprising: 

a card deck stored in said memory. 

38. A two-way data communication device as in Claim 37 wherein said card deck includes a choice card. 
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39. A two-way data communication device as in Claim 38 whe-ein upon said client module processing said choice card, 
said client module retrieves said stored information identifying the pressed key. and generates a request for a 
choice corresponding to the pressed key to said server (121.131.141). 



10 



15 



20 



25 



30 



35 



40 



45 



SO 



55 



68 

4SOOCID: <EP_0779759A2_I_> 



EP0779 759A2 




EP 0 779 759 A2 



m. 2A 



FIG. 2B 



nc. 2C 



FIG. 2D 




1 XYZ Corp. Sales 



105 
J- 



2 Personal Information 

3 SuperTel Service 

4 Directory of Services 



XYZ Corp. Sales Support 
1 Enter new order 



2 Check open order 



3 Customer credit check 



Home 



204 



Info 



105 

J. 



202 



203 



205 




70 



4SQCX:iD: <EP_07797S9A2_I_> 



EP 0 779 759 A2 



FIG. 2E 




FIG. 2F 



P.O.: 11-11-11 
Cust: ABC Designs 
Dote: March 3, 1994 
Ship: Morch 7. 1994 



Prev. 



207 



Fax 



105 

^. — 209 
GJ-203 



208 



105 



FIG. 2G 



FIG. 2H 



Fox details to what 




number: 






Prev. 




105 




/ 


Fax details to whot 




number 




(415) 341-4473 


Prev. 



4SDOCID: <EP_0779759A2_L> 



71 



EP0 779 759 A2 



CO 
CD 



to 



m 

I 



4 



a> 



= 1 

=3 O 
I O 

m 

CD 

o c=> 

CN| to 



to 




E 

CO 



OD 
<D 

O 

Clu 



a> CD 

ID 

a> CT 
o cr 
c o 
o x= 
O O 



o 

CO 



CO 



CO 



CO 




72 



iSDOClD: <EP_0779759A2_I_> 



EP 0 779 759 A2 



to 





















Enter ticker symbol i 
the stock: 


SUNW 


AirNet 



5 



. to 



E ^ 



cm 



CO 



to m 

St CO 

'T* ITJ Q. 

a> 



S to 

• CO 

to 
• CO 

* • o *— - 



.bi ^ CSI CN| 
CD •< CO to 



O CT> 



CO 







4H 


9 








I ill* 




to 



—5 



5 



9 



C3 



to 



to 

CD 

to 

CM 



to 



o 




o 
O 

11 

c3 a> 



CO 



Q_ or 



cvi 



CO 

o 
ro 



to 



—5 




g 



g 



g 



73 



iSOOCiD: <EP_0779759A2_I_> 



EPO 779 759 A2 




EP0 779 759 A2 




SIXXID: <EP_0779759A2J_> 



EP 0 779 759 A2 




I?. 



o 
o 



CO 



o 



4- 



5 



8; 




CO 

r^- — 1 


to 

lO 


CO 


p-4 — 1 


Q- 


MEMORY 


HL 
DECKS 



CO 




^ dan T "- 



CM 



1= 

CO O 



Ho 



SO 



CM 




i 



If 



76 



JSOCCID: <EP_0779758A2J_> 



EP 0 779 759 A2 



CUENT 
MODULE 
702 



810 



800 



811 

6 



812 




GET 
HOME URL 



CREATE 
HTTP REQUEST 



-801 



-802 



^(TCP ONLY) 

~ESfABUSH~"l"^°^ 
SERVER !-•- — 
CONNECTION ! 





TRANSMrr • 




REQUEST 












S<806 


NO 


/RESPONSES 



-804 



lECElVm. 

[yes 

i transmission c- 
! complete ' 



i 



1 



PROCESS 
RRST CARD 



GENERATE 
DISPLAY 



'808 



-809 



L. 



813 



HTTP 
SERVER 
749 



I ESTABUSH 
J CUENT 

i CONNECTION 

I (TCP OHli) 



■860 




TRANSMIT 
RESPONSE 



I 



END 



FIG. 8A 



77 



_0779759A2J_> 



EP 0 779 759 A2 



0^813 




m. SB 



78 

0779758A2J_> 



EP 0 779 759 A2 




JSDOCID: <EP_077S7SeA2J_> 



EP0 779 759A2 





80 

4SDCX;iD: <EP 07797S9A2 I > 



EP0779 759A2 



(1 


II 


1 


2 


3 


4 


5 


6 


7 


8 


9 


"a 


a" 


q 


a 


d 


g 


j 


m 


r 


t 


w 


"a 


b" 


q 


a 


e 


i 




o 


r 




w 


"a 


c" 


q 


c 


e 


h 




m 


r 


t 


w 


"a 


d" 


q 


a 


d 


i 


j 


m 


s 




y 


"a 


e" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"a 


r 


q 


a 


f 


g 


j 


m 


r 


t 


w 


"a 


g" 


q 


a 


e 


i 


j 


0 


r 


t 


w 


"a 


h" 


q 


a 


e 


g 


j 


m 


P 




w 


"a 


i" 


q 


c 


d 


g 


1 


n 


r 


t 


w 


"a 


j" 


q 


a 


d 


g 


j 


o 


P 


t 


w 


"a 


k" 


q 


a 


e 


i 


j 


m 


s 


t 


w 


"a 


r 


q 


a 


e 


i 


1 


o 


s 


t 


w 


"a 


m" 


q 


a 


e 


i 


1 


o 


P 




w 


"a 


n" 


q 


c 


d 


g 


k 


n 


s 


t 


y 


"a 


o" 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"a 


P" 


q 


a 


e 


h 


1 


o 


p 


t 


w 


"a 


q" 


q 


a 


d 


g 


j 


m 


s 


t 


w 


"a 


r" 


q 


c 


e 


g 


k 


o 


r 


t 


y 


"a 


s" 


q 


c 


e 


i 


k 


o 


s 


t 


y 


"a 


t" 


q 


a 


e 


i 


1 


o 


s 


t 


w 


"a 


u" 


q 


c 


d 


g 


1 


m 


s 


t 


w 


"a 


V" 


q 


a 


e 


i 


j 


o 


p 


t 


w 


"a 


w" 


q 


a 


d 


g 


k 


m 


p 


t 


w 


"a 


X" 


q 


a 


e 


i 


1 


m 


s 


t 


w 


"a 


y" 


q 


b 


e 


i 


j 


m 


s 


t 


w 


"a 


z" 


q 


a 


d 


i 


j 


m 


p 


t 


w 


"a 


II 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"b 


a" 


q 


c 


d 


g 


k 


n 


s 


t 


y 


"b 


b" 


q 


a 


d 


i 




m 


s 




y 


"b 


c" 


q 


a 


d 


g 




o 


r 




w 


"b 


d" 


q 


a 


d 


g 




m 


s 




w 


"b 


e" 


q 


c 


e 


g 




n 


s 




X 


"b 


r 


q 


a 


d 


g 




m 


p 




w 


"b 


g" 


q 


a 


d 


g 




m 


p 




w 


"b 


h" 


q 


a 


d 


g 




m 


p 




w 


"b 


i" 


q 


c 


d 


g 




n 


s 




w 


"b 




q 


a 


e 


g 


j 


m 


p 







FIG. lOA 



81 



^SDOCID: <EP__0779759A2_I_> 



EP 0 779 759 A2 







1 


2 


3 


4 


5 


6 


7 


8 


Q 


"b 


k" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"b 


1" 


q 


a 


e 


i 


j 


o 


p 




y 


"b 


m" 


q 


a 


d 


g 


j 


m 


r 




w 


"b 


n" 


q 


a 


d 


g 


j 


m 


p 


I 


w 


"b 


0" 


q 


a 


d 


i 


j 


o 


s 


u 


X 


"b 


P" 


q 


a 


d 


g 


j 


m 


s 




w 


"b 


q" 


q 
* 


a 


d 


g 


j 


m 


p 


( 


w 


"b 


r" 


q 


a 


e 


i 


j 


o 


P 


u 


w 


"b 


s" 


q 


c 


d 


i 


j 


o 


s 




w 


"b 


t" 


q 


a 


d 


g 


j 


m 


p 




w 


"b 


u" 


q 


a 


d 


i 




m 


s 


I 


V 

J 


"b 


V" 


q 


a 


d 


i 


j 


m 


p 


I 


w 


"b 


w" 


q 


a 


e 


g 


j 


m 


p 




w 


"b 


X" 


q 


a 


d 


g 




m 


P 




w 


"b 


y" 


q 


a 


d 


g 


j 


m 


P 




w 


"b 


z" 


q 


a 


d 


g 


j 
J 


m 


P 




w 


"b 


II 


q 


a 


d 


g 




m 


P 




w 


"c 


a" 


q 


b 


d 


g 




n 


r 




w 


"c 


b" 


q 


a 


e 


g 


j 
J 


m 


p 




w 


"c 


c" 


q 


a 


e 


i 


j 


o 


s 


I 


w 


"c 


d" 


q 


a 


d 


g 


j 


m 


p 


I 


w 


"c 


e" 


q 


a 


d 


i 




n 


s 


I 


w 


"c 


r 


q 


a 


d 


i 


j 


m 


p 


I 


w 


"c 


g" 


q 


a 


d 


i 


j 


m 


p 




w 


"c 


h" 


q 


a 


e 


i 




0 


r 


t 


w 


"c 


i" 


q 


a 


f 


i 




n 


p 




w 


"c 


j" 


q 


a 


d 


g 


j 


m 


p 


( 


w 


"c 


k" 


q 


b 


e 


i 




m 


s 


t 


y 


"c 


1" 


q 


a 


e 


i 




o 


r 


u 


w 


"c 


m" 


q 


c 


d 


g 


j 


m 


P 




w 


"c 


n" 


q 


a 


d 


g 


j 


m 


P 




w 


"c 


0" 


q 


a 


d 


g 




m 


r 


u 


w 


"c 


P" 


q 


a 


d 


g 


j 


m 


P 




w 


"c 


q" 


q 


a 


d 


g 


j 


m 


P 




w 


"c 


r" 


q 


a 


e 


i 


j 


o 


P 


u 


y 


"c 


s" 


q 


a 


d 


i 


1 


o 


s 


t 


w 


"c 


t" 


q 


a 


e 


i 


I 


0 


r 


u 


w 



FIG. lOB 



82 

4SDOCID: <EP_0779759A2L1_> 



EP0 779 759A2 



II 


II 


1 
1 


2 

Am 


D 


A 




ft 


7 


» 


Q 


"c 


u" 


q 


b 


e 


i 


J 


m 


s 




w 


"c 


V" 


q 


a 


d 


o 


j 


m 


p 




w 


"c 


w" 


q 


a 


d 


p 

o 


j 


m 


n 

K 




w 


"c 


x" 


q 


a 


d 


g 


j 


m 


P 




w 


"c 


y" 


q 


c 


d 


g 


j 


m 


P 




w 


"c 


z" 


q 
* 


a 


d 


e 

o 


j 


n 


P 


J. 


w 


"c 


It 


q 


a 


d 


p 

e 


J 


m 


n 




w 


"d 


a" 


q 


b 


d 


£ 


j 


n 


r 




y 


"d 


b" 


q 


a 


d 


g 


j 


m 


P 

Mr 




w 


"d 


c" 


q 


a 


d 


g 


j 


m 


P 




w 


"d 


d" 


q 


a 


e 


i 




m 


r 


I 


w 


"d 


e" 


q 


a 


d 


g 




m 


r 


V 


X 


"d 


r 


q 


a 


d 


i 


j 


m 


p 


t 


w 


"d 


g" 


q 


a 


e 


g 


j 


m 


P 


t 


w 


"d 


h" 


q 


a 


e 


g 


j 


m 


p 


I 


w 


"d 


i" 


z 


a 


f 


g 


[ 


n 


s 


I 


w 


"d 


j" 


q 


a 


d 


g 


j 


m 


p 


( 


w 


"d 


k" 


q 


a 


d 


g 


j 


m 


P 

Mr 




w 


"d 


1" 


n 

M 


a 


e 


i 


j 


ixi 


n 




V 

J 


"d 


m" 


n 
H 




d 


i 


j 


m 


s 




w 


"d 


n" 


a 


a 


e 


p 

o 


j 


m 


n 




w 


"d 


o" 


n 
M 


c 


e 


i 


j 


n 


n 




w 


"d 


p" 

Mr 


Q 


a 


d 


p 




m 


n 
y 




w 


"d 




q 


a 


d 


g 


j 


m 


p 


u 


w 


"d 


r" 


q 


a 


e 


i 


j 


o 


P 

Mr 




w 


"d 


s" 


Q 


a 


e 


i 


j 


m 


n 

Mr 




w 


"d 


t" 


q 


a 


d 


g 


j 


m 


r 




w 


"d 


u" 


q 


c 


e 


g 


1 


m 


r 


t 


w 


"d 


v" 


q 


a 


d 


i 




m 


P 




w 


"d 


w" 


q 


a 


d 


i 




o 


P 




w 


"d 


X" 


q 


a 


d 


g 




m 


P 




w 


"d 


y" 


q 


a 


d 


g 




m 


P 




w 


"d 


z" 


q 


a 


d 


g 




m 


P 




w 


"d 


It 


q 


a 


d 


g 




m 


P 




w 


"e 


a" 


q 


c 


d 


g 




n 


s 




w 


"e 


b" 


q 


c 


f 


g 


j 


m 


r 




y 


"e 


c" 


q 


a 


e 


h 


k 


o 


s 




w 



BIG. IOC 



83 

4SDCX;iD: <EP__0779759A2J_> 



EP 0 779 759 A2 







1 


2 


3 


4 


5 


6 


7 


8 


9 






q 


D 


e 




1 
1 


n 


s 


u 


w 


e 


e 


z 


a 


G 


! 


k 


n 


r 


t 


w 


C 


r 




a 


e 




1 
1 


o 


r 


t 


w 


e 


It 

g 


q 


a 


d 


! 


j 


o 


r 


u 


y 




n 


q 


a 


e 




j 


m 


P 


t 


w 


e 


1 


q 


a 


a 


g 


j 


n 


r 


V 


w 


II 

e 


J 


q 


a 


e 


g 


j 


m 


P 


t 


w 


e 


K 


q 


a 


e 


! 


j 


m 


s 


t 


w 




1 


q 


a 


e 


! 


1 
1 


o 


P 


V 


y 


e 


m 


q 


a 


e 


* 


j 


o 


s 


u 


w 


C 


r*" 

n 


q 


c 


a 


g 


1 
1 


o 


s 


t 


w 


c 


o 


q 


a 


T 


g 


j 


n 


p 


u 


w 


"e 


d" 
p 


n 


o 
a 






1 
i 


/-\ 
u 


r 


t 


w 


"p 


n" 


f-j 
H 




u 


g 


j 


m 


P 


u 


w 


C 


r" 
i 


H 




C 


! 


1 
1 


n 


S 


V 


y 


C 


s 




c 


e 




K 


n 


s 


t 


w 


c 


r" 
I 




c 


c 




j 


m 


s 


t 


w 




U 


q 


a 


a 


g 




m 


r 


t 


w 


e 


V 


q 


a 


e 


i 




o 


P 


t 


w 


e 


w 


q 


a 


e 


n 




0 


s 


t 


w 


e 


X 


q 


a 


e 


i 




m 


P 


t 


w 


e 


y 


q 


a 


a 


g 


j 


o 


s 


t 


w 


e 


Z 


q 


a 


e 


g 


j 


m 


p 


t 


w 


e 


ft 


q 


a 


a 


g 




m 


p 


t 


w 


I 


a 


q 


c 


a 


i 


K 


m 


s 


V 


X 


T 


b 


q 


a 


a 


g 


J 


m 


p 


t 


w 


I 




4 


c 


u 


g 


j 


m 


p 


I 


w 


i 


it 


H 


a. 


u 


g 


j 


m 


p 


*■ 

I 


w 


"f 


e" 


q 


a 


e 


g 




m 


r 


t 


w 


"f 


r 


q 


a 


e 


i 


j 


0 


s 


t 


w 


"f 


g" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"f 


h" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"f 


i" 


q 


c 


e 


g 




n 


r 


t 


X 


"f 


j" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"f 


k" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"f 


1" 


q 


a 


e 


i 


j 


o 


P 


t 


y 


"f 


m" 


q 


a 


d 


g 


j 


m 


P 


t 


w 



FIG. lOD 



84 

4SDOCtD: <EP_0779759A2_L> 



EP 0 779 759 A2 



tl 


n 


1 


2 


3 


4 


5 


6 


7 


8 


9 


"f 


n" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"f 


o" 


q 


c 


d 


g 


1 


n 


r 


u 


w 


"f 


P" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"f 


q" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"f 


r" 


q 


a 


e 


i 


j 


o 


P 


t 


y 


"f 


s" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"f 


t" 


q 


a 


e 


g 


k 


m 


P 


t 


w 


"f 


u" 


q 


a 


d 


g 


1 


n 


r 


t 


w 


"f 


V" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"f 


w" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"f 


X" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"f 


y" 


q 


a 


d 


i 


j 


m 


P 


t 


w 


"f 


z" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"f 


It 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"g 


a" 


z 


a 


d 


i 


1 


n 


r 


t 


w 


"g 


b" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"g 


c" 


q 


a 


d 


g 


j 


m 


s 


t 


w 


"g 


d" 


q 


a 


d 


g 


j 


o 


P 


t 


w 


"g 


e" 


q 


a 


d 


g 


1 


n 


s 


t 


w 


"g 


r 


q 


a 


d 


g 


j 


m 


p 


u 


w 


"g 


g" 


q 


a 


e 


g 


1 


m 


p 


t 


w 


"g 


h" 


q 


a 


e 


g 


j 


o 


p 


t 


w 


"g 


i" 


q 


c 


f 


g 


j 


n 


s 


V 


w 


"g 


j" 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"g 


k" 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"g 


1" 


q 


a 


e 


i 


j 


o 


p 


t 


y 


"g 


m" 


q 


a 


d 


g 


1 


m 


s 


t 


w 


"g 


n" 


q 


a 


e 


i 




o 


p 




w 


"g 


o" 


q 


a 


e 


i 




o 


p 




w 


"g 


P" 


q 


a 


d 


g 




m 


p 




w 


"g 


q" 


q 


a 


d 


g 




m 


p 




w 


"g 


r" 


q 


a 


e 


g 




o 


p 




w 


"g 


s" 


q 


a 


d 


g 




m 


p 




w 


"g 


t" 


q 


a 


e 


h 




o 


p 




w 


"g 


u" 


q 


a 


e 


i 




m 


r 




y 


"g 


V" 


q 


a 


d 


g 




m 


P 




w 


"g 




q 


a 


d 


g 




m 


P 




w 



FIG. lOE 



85 

4SOOC1D: <EP__0779759A2J_> 



EP 0 779 759 A2 



tl 


n 


1 


2 


3 


4 


5 


6 


7 


8 


9 


g 


. II 

X 


q 


a 


d 


g 


J 


m 


P 




w 


tf 

g 


y" 


q 


a 


d 


g 


J 


m 


P 


t 


w 


"g 


z" 


q 


a 


d 


g 


J 


m 


P 




w 


"g 




q 


a 


d 


g 


j 


m 


P 




w 


"h 


a" 


q 


b 


d 


i 




n 


s 




w 


"h 


b" 


q 


a 


d 


g 


j 


m 


P 




w 


n 


c 


q 


a 


a 


g 


J 


0 


P 




w 


n 


d 


q 


a 


d 


g 


J 


m 


r 




w 


n 


— •< 
e 


q 


c 


d 


i 




n 


r 




y 


h 


^1 
f 


q 


a 


d 


g 


J 


m 


P 




w 


n 


g 


q 


a 


d 


g 


J 


m 


P 




w 


n 


I, II 
n 


q 


a 


d 


g 


J 


m 


P 




w 


n 


: " 
1 


q 


c 


e 


g 


! 


n 


s 




w 


n 


J 


q 


a 


a 


g 




m 


P 




w 


n 


k 


q 


a 


d 


g 


j 


m 


P 




w 


h 


1 1I 
1 


q 


a 


d 


g 


J 


m 


P 




y 


n 


m 


q 


a 


e 


g 


j 


m 


P 




w 


■1 « 
h 


n" 


q 


a 


d 


i 


j 


o 


P 


t 


w 


"h 


o" 


q 


b 


d 


i 


1 


n 


r 


u 


w 


"h 


P" 


q 


a 


d 


g 


j 


m 


P 


u 


w 


"h 


q" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"h 


r" 


q 


a 


e 


i 


j 


o 


P 


t 


w 


"h 


s" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"h 


t" 


q 


a 


d 


g 




m 


s 


t 


w 


"h 


u" 


q 


a 


d 


g 


j 


m 


r 


t 


w 


"h 


v" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"h 


w" 


q 


a 


d 


g 


j 


m 


P 




w 


h 


X 


q 


a 


d 


g 




m 


P 




w 


"h 


y" 


q 


a 


d 


g 




m 


P 




w 


"h 


z" 


q 


a 


d 


g 




m 


P 




w 


"h 




q 


a 


d 


g 




m 


P 




w 


tl ; 


a" 


q 


b 


d 


g 




n 


r 




w 


tl ' 


b" 


q 


a 


e 


i 




m 


r 


u 


w 


n ' 


c" 


q 


a 


e 


h 


k 


0 


r 




y 


fi : 


d" 


q 


a 


e 


i 




n 


P 


u 


w 


II * 


e" 


q 


c 


d 


g 




n 


r 


V 


w 


tf ' 


f 


q 


a 


f 


i 




0 


P 




y 



FIG. lOF 



86 

4SOOCID: <EP__0779759A2_I_> 



EP0 779 759 A2 



fl 


It 


1 


2 


3 


4 


5 


6 


7 


8 


9 


"i 


g" 


q 


a 


e 


h 


j 


n 


r 


u 


w 


"i 


h" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"i 


i" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"i 


j" 


q 


a 


d 


g 


j 


o 


P 


t 


w 


"i 


k" 


q 


a 


e 


g 


k 


m 


P 


t 


w 


"i 


1" 


q 


a 


e 


i 


1 


o 


s 


t 


y 


"i 


m" 


q 


a 


e 


i 


j 


m 


P 


u 


w 


"i 


n" 


q 


c 


e 


g 


k 


n 


s 


t 


w 


"i 


o" 


q 


a 


d 


g 


1 


n 


r 


u 


w 


"i 


P" 


q 


a 


d 


i 


I 


m 


s 


t 


w 


"i 


q" 


q 


a 


d 


g 


j 


m 


P 


u 


w 


"i 


r" 


q 


c 


e 


i 


1 


n 


s 


t 


w 


"i 


s" 


q 


c 


e 


h 


k 


n 


s 


t 


w 


"i 


t" 


q 


a 


e 


h 


1 


0 


s 


t 


y 


"i 


u" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


**i 


v" 


q 


a 


e 


i 


j 


m 


p 


t 


w 


"i 


w" 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"i 


X" 


q 


a 


e 


g 


j 


m 


p 


t 


w 


"i 


y" 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"i 


z" 


q 


a 


e 


i 


j 


o 


p 


t 


w 


"i 


If 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"j 


a" 


q 


c 


d 


g 


j 


n 


p 


t 


w 


"j 


b" 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"j 


c" 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"j 


d" 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"j 


e" 


q 


c 


d 


g 


j 


m 


r 


t 


w 


"j 


r 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"j 


g" 


q 


a 


d 


g 




m 


P 




w 


"j 


h" 


q 


a 


d 


g 




m 


P 




w 


"j 


i" 


q 


a 


d 


g 




m 


P 




w 


"j 


j" 


q 


a 


d 


g 




m 


P 




w 


"j 


k" 


q 


a 


d 


g 




m 


P 




w 


"j 


1" 


q 


a 


d 


g 




m 


P 




w 


"j 


m" 


q 


a 


d 


g 




m 


P 




w 


"j 


n" 


q 


a 


d 


g 




m 


P 




w 


"j 


o" 


q 


b 


e 


i 




m 


r 




w 


"j 


P" 


q 


a 


d 


g 




m 


P 




w 



FIG. 106 



87 

iSDOCID: <EP__0779759A2_L> 



EP 0 779 759 A2 





if 


1 


2 


J 




q 


a 


J 


—tl 

r 


q 


a 


II * 

J 


If 

s 


q 


a 


"j 


t" 


q 


a 


tl " 

J 


u" 


q 


a 


"j 


v" 


q 


a 


"j 


w" 


q 


a 


"j 


x" 


q 


a 


J 


_ . 11 

y 


q 


a 


"j 


z" 


q 


a 


"j 




q 


a 


k 


a 


q 


a 


k 


i_ tl 
b 


q 


a 


k 


c" 


q 


a 


It t. 
k 


d 


q 


a 


k 


^ tl 
e 


q 


a 


k 


^1 
r 


q 


a 


k 


«ti 

g 


q 


a 


k 


n 


q 


a 


Tl 1 

k 


• tl 
1 


q 


a 


til. 
k 


: tt 

J 


q 


a 


I1 1. 
k 


1 tl 

k 


q 


a 


"k 


1" 


q 


a 


"k 


in" 


q 


a 


"k 


n" 


q 


a 


k 


o" 


q 


a 


II 1 
k 


P" 


q 


a 


K 




q 


a 


"k 


r" 


q 


a 


"k 


s" 


q 


a 


"k 


t" 


q 


a 


"k 


u" 


q 


a 


"k 


V" 


q 


a 


"k 


w" 


q 


a 


"k 


X" 


q 


a 


"k 


y" 


q 


a 


"k 


z" 


q 


a 



JSDCXJID: <EP__0779769A2J_> 



3 


4 


5 


6 


7 


8 


9 


0 


g 


J 


m 


P 




w 


d 


g 


J 


m 


P 




w 


d 


g 


J 


m 


P 




w 


d 


g 


J 


m 


P 




w 


d 


g 


1 


m 


s 




w 


d 


g 


J 


m 


P 




w 


d 


g 


J 


m 


P 




w 


d 


g 


J 


m 


P 




w 


d 


g 


J 


m 


P 




w 


d 


g 


J 


m 


P 




w 


d 


g 


J 


m 


P 




w 


a 


g 


J 


n 


s 




y 


G 


g 


J 


o 


p 




w 


G 


g 


J 


m 


p 




w 


G 


g 


J 


0 


p 




w 


G 


g 


! 


n 


s 




y 


G 


g 


J 


m 


p 




w 


d 


g 


J 


m 


r 




w 


d 


g 


J 


m 


P 




w 


d 


g 


1 


n 


P 




w 


d 


g 


J 


m 


P 




w 


d 


g 


j 


o 


P 




w 


d 


i 


j 


m 


P 




y 


d 


g 


J 


m 


P 




w 


d 


g 


J 


0 


P 




w 


d 


g 


1 


n 


P 




w 


d 


g 




m 


P 




w 


d 


g 


i 


m 


P 




w 




a 
B 




m 
111 


P 




w 


d 


g 




m 


P 




w 


d 


g 




m 


P 




w 


d 


g 




m 


P 




w 


d 


g 




m 


P 




w 


d 


g 




m 


P 




w 


d 


g 




m 


P 




w 


d 


g 




m 


P 




w 


d 


g 




m 


P 




w 



FIG. lOH 

88 



EP 0 779 759 A2 



123456789 



"k " q a d g j m p t w 

"la" q b d i j n r t y 

"lb" q a d g j o p t w 

"1 c" q a d g j o p t w 

"Id" q a e i j n s t w 

"I e" q a d g I m s t X 

"If q a d g j m p t w 

"1 g" q a d g j m p t w 

"1 h" q a d g j m p t w 

"1 i" z c e g k n s t w 

"1 j" q a d g j m p t w 

"Ik" q a e i j m s t w 

"11" q c e i j o s u y 

"1 m" q a d g j o s t w 

"In" q a e g j m p t w 

"lo" qcdgjostw 

"1 p" q a d h j m s t w 

"1 q" q a d g j m p t w 

"1 r" q a e g j m p t w 

"Is" q a e i j o p t w 

"It" qaeijostw 

"1 u" q c d g 1 m s t w 

"1 v" q a e i j m p t w 

"I w" q a e g j m p t w 

"I X" q a d g j m p t w 

"I y" z a d i j n s t w 

"Iz" qadgjmptw 

"1 " qadg j mptw 

"ma" q c d i k n r t y 

"m b" q a e i 1 m p t y 

"m c" q c d i j o p t w 

"rod" qadgjmptw 

"me" q a e g 1 n s t w 

"mf qadgjoptw 

"m g" qadgj m p t w 

"m h" z a d g j m p t w 

"mi" z c d g 1 n s t X 



FIG. 101 

89 



JSDOCID: <EP 0779759A2 1 > 



EP 0 779 759 A2 



*■ 


II 


1 


2 


3 


4 


5 


6 


7 


8 


9 


"m 
111 


i" 
J 




a 


H 
\x 


S 




m 
111 


n 

V 




w 


m 
111 




r\ 

H 


p 
a 


A 

\X 


& 




m 
111 


n 

V 




W 


111 


1 


c\ 


Q 

a. 


c 


g 


\ 


m 
111 


P 




y 


"m 
111 


m" 
111 




d. 




1 


\ 


c\ 
yj 


P 




VV 


rn 


n" 

n 




o 

a 


Q 


g 


\ 


in 


P 




w 


"m 

m 


ri" 
O 




O 


H 
U 


1 


\ 


n 


r 




w 


m 


P 


Q 


3. 


C 


1 


\ 


o 


r 




w 


m 




Q 




Q 


g 


\ 


m 


P 




w 


m 


r 


q 


a 


a 


g 


\ 


m 


P 




w 


It 

m 


s 


q 


a 


e 


g 


\ 


m 


P 




w 


m 


I 


q 


a 


Q 


g 




m 


P 




w 


m 


u 


q 


c 


J 
Q 


g 


! 


n 


s 




w 


m 


V 


q 


a 


a 


g 


\ 


m 


P 




w 


m 


W 


q 


a 


a 


n 


\ 


m 


P 




w 


m 


X 


q 


a 


Q 


g 


J 


m 


P 




w 


"m 


y 


q 


c 


a 


g 


\ 


m 


s 




w 


"m 
Hi 




q 


a 


u 


fir 

g 


\ 


m 


p 




w 


tt 

m 


fi 


q 


a 


d 


g 




m 


p 




w 


n 


a 


q 


D 


Q 


g 


! 


m 


r 




w 


n 


D 


q 


a 


a 


g 




m 


p 




w 




c" 


4 


p 


w 






yj 


1 




y 


"n 
11 


LI 


4 


o 

a 


C 


. 

! 




\J 


c 
O 




y 


n 


*»" 




C 


6 


! 


: 


n 


s 




w 


n 


I 




a 


c 


! 


•j 


0 


s 


u 


w 


11 


p" 
& 


4 


p 








m 
111 


c 


u 


w 


"n 
11 


11 


4 


Q 

a 


ii 


g 




III 


P 




w 


11 


i" 

A 


'J 

Ma 


r» 


p 


Q 
& 




II 


c 




A 


"n 
11 


i" 
J 


CI 

q 


o 
d 


A 

sx 


g 




m 
ill 


p 


11 

u 


w 


"n 


k" 


q 


a 


e 


i 




n 


s 




w 


"n 


1" 


q 


a 


e 


i 




o 


p 




y 


"n 


m" 


q 


a 


e 


g 




m 


p 




w 


"n 


n" 


q 


a 


e 


i 




0 


p 


U 


y 


"n 


o" 


q 


b 


d 


g 




n 


r 




w 


"n 


P" 


q 


a 


d 


g 




o 


P 


U 


w 


"n 


q" 


q 


a 


d 


g 




m 


P 


U 


w 


"n 


r" 


q 


a 


d 


g 




m 


P 




w 


"n 


s" 


q 


a 


e 


i 




m 


P 




w 



nc. loj 



90 

VSDOCIO: <EP_07797S9A2_L> 



i 



EP 0 779 759 A2 



11 


11 


1 


2 


3 


4 


5 


6 


7 


8 


9 


"n 


t" 


q 


a 


e 


i 


1 


0 


s 


u 


y 


"n 


u" 


q 


a 


f 


g 


j 


m 


s 


t 


X 


"n 


v" 


q 


a 


e 


i 


j 


o 


P 


t 


w 


"n 


w" 


q 


a 


e 


g 


j 


m 


P 




w 


"n 


X" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"n 


y" 


q 


b 


d 


h 


j 


m 


P 


t 


w 


"n 


z" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"n 


fl 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"0 


a" 


q 


b 


d 


g 


1 


m 


s 


t 


w 


"o 


b" 


q 


a 


e 


i 


1 


o 


s 


t 


w 


"o 


c" 


q 


a 


e 


h 


k 


o 


s 




w 


"o 


d" 


q 


a 


e 


i 


1 


o 


s 




y 


"o 


e" 


q 


a 


d 


g 


j 


m 


s 


t 


w 


"0 


f 


q 


a 


f 


g 


j 


m 


p 


t 


w 


"o 


g" 


q 


a 


e 


i 


j 


o 


r 


t 


y 


"o 


h" 


q 


a 


d 


g 


j 


n 


P 


t 


w 


"o 


i" 


q 


c 


d 


g 


1 


n 


P 


t 


w 


"o 


j" 


q 


a 


e 


g 


j 


m 


P 


t 


w 


"o 


k" 


q 


a 


e 


i 


j 


m 


s 


t 


w 


"o 


r 


q 


b 


d 


i 


I 


o 


s 




w 


"o 


m" 


q 


a 


e 


i 


1 


m 


P 


t 


w 


"o 


n" 


q 


a 


e 


g 


1 


n 


s 


t 


y 


"o 


0" 


q 


a 


d 


g 


k 


n 


s 


t 


w 


"0 


P" 


q 


a 


e 


h 


I 


m 


p 


t 


y 


"o 


q" 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"o 


r" 


q 


a 


e 


g 


k 


m 


r 


t 


w 


"o 


s" 


q 


c 


e 


i 


j 


o 


s 




y 


"o 


t" 


q 


a 


e 


h 


j 


0 


s 




y 


"o 


u" 


q 


c 


d 


g 


I 


n 


r 




y 


"o 


V" 


q 


a 


e 


i 


j 


m 


P 




w 


"o 


w" 


q 


a 


e 


i 


j 


n 


s 




w 


"o 


x" 


q 


a 


d 


i 


j 


m 


P 




w 


"o 


y" 


q 


a 


e 


g 


j 


m 


s 




w 


"o 


z" 


q 


a 


d 


g 


j 


ra 


p 




w 


"o 


It 


q 


a 


d 


g 


j 


m 


p 




w 


"p 


a" 


q 


c 


d 


g 


1 


n 


r 




y 


"p 


b" 


q 


a 


e 


g 


j 


m 


P 




w 



FIG. iOK 



91 

4SDOCID; <EP 0779759A2 I > 



EP 0 779 759 A2 



r 



- 


-** 


1 


2 


3 


4 


5 


6 


7 


8 


9 


V 




4 




d 

u 


o 
a 




m 
III 


c 




W 


P 


fl" 


c\ 
M 


d 


A 
W 


g 


•! 


111 


p 




VV 


P 


c 


f\ 
M 




A 
\X 


fj 
g 


•! 


Tl 
11 


r 




W 


P 


I 




d 


A 

\X 


g 


•! 


m 


r 




w 


P 


p" 


M 


<1 




or 
g 




m 
111 


P 




w 


P 


it 


4 


o 
<x 




1 


. 


r\ 
\J 


c 

o. 




y 


P 


1 


4 




A 

u 


g 


I 


n 


t" 

1 




Y 

A 


P 


i" 
J 


q 


a 


A 
KX 


S 


\ 


nn 
111 


P 




w 


P 


K 


q 


a 


a 


g 


\ 


m 


P 




W 


P 


1" 
1 


^1 


o 

a 




1 
1 


\ 


o 


P 




y 


P 


lU 


Q 


a 


c 


g 


\ 


111 


P 




1.1/ 

w 


P 


n" 

n 


q 


d. 


A 
\1 


g 


•j 


ni 


P 




w 


P 


o 


q 


c 


A 


1 


I 


n 


r 




w 


P 


p 


q 


a 


6 


1 


! 


0 


P 




y 


P 


q 


q 


H 


u 


g 


\ 


m 


P 




w 


P 


r 


q 




c 


1 


\ 


o 


P 




y 


P 


s 


q 


a 


Q 


g 


\ 


m 


P 




w 


P 


1-" 

L 


q 


C 


6 


1 


J 


o 


s 




w 


P 


II 

u 


q 


o 


d 


g 


J 


m 


r 




w 


P 


V 


q 


a 


A 

a 


g 


J 


m 


P 




w 


P 


.11 

w 


q 


a 


a 


g 


J 


m 


P 




w 


P 


X 


q 


a 


a 


g 


J 


m 


P 




w 


P 


«,ii 

y 


q 


a 


a 


g 


J 


m 


r 




w 


P 


z 


q 


a 


d 


g 


•! 


m 


P 




w 


P 


tl 


q 


a 


d 


g 


\ 


m 


P 




w 




a 


q 


a 


u 


g 


\ 


rn 


P 




w 


q 


D 


q 


a 


A 

a 


g 


\ 


m 


P 




w 




r" 


4 


d 


A 
\X 


g 




111 


p 




w 


"q 


d" 


q 


a 


d 


g 




m 


p 




w 


"q 


e" 


q 


a 


d 


g 




m 


p 




w 


"q 


r 


q 


a 


d 


g 




m 


p 




w 


"q 


g" 


q 


a 


d 


g 




m 


p 




w 


"q 


h" 


q 


a 


d 


g 




m 


p 




w 


"q 


i" 


q 


a 


d 


g 




m 


p 




w 


"q 


j" 


q 


a 


d 


g 




m 


p 




w 


"q 


k" 


q 


a 


d 


g 




m 


p 




w 


"q 


1" 


q 


a 


d 


g 




m 


p 




w 



FIG. lOL 



4SDOCID: <EP_07797S9A2_L> 



r 



EP 0 779 759 A2 



11 


11 


I 


2 


3 


4 


5 


6 


7 


8 


9 


"q 


m" 


q 


a 


d 


g 


. 

J 


m 


P 




w 


"q 


n" 


q 


a 


d 


g 


J 


m 


P 




w 


"q 


o" 


q 


a 


d 


g 


J 


m 


P 




w 


"q 


P" 


q 


a 


d 


g 


J 


m 


P 




w 


"q 


q" 


q 


a 


d 


g 


J 


m 


P 




w 


"q 


r" 


q 


a 


d 


g 


j 


m 


P 




w 


"q 


s" 


q 


a 


d 


g 


J 


m 


P 




w 


"q 


t" 


q 


a 


d 


g 


j 


m 


P 




w 


-q 


u" 


q 


a 


e 


i 


j 


o 


P 




w 


"q 


v" 


q 


a 


d 


g 


j 


m 


P 




w 


"q 


w" 


q 


a 


d 


g 


j 


m 


P 




w 


"q 


X" 


q 


a 


d 


g 


j 


m 


P 




w 


"q 


y" 


q 


a 


d 


g 


j 


m 


P 




w 


"q 


z" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"q 


M 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"r 


a" 


q 


c 


d 


g 


1 


n 


P 


t 


w 


"r 


b" 


q 


a 


d 


g 


j 


o 


P 




w 


•r 


c" 


q 


a 


e 


h 


1 


m 


P 


u 


w 


"r 


d" 


q 


a 


e 


i 


j 


n 


s 


V 


w 


"r 


e" 


q 


a 


e 


g 




n 


s 


V 


w 


"r 


r 


q 


a 


e 


g 


j 


o 


P 


t 


w 


"r 


g" 


q 


a 


e 


i 


j 


m 


s 


u 


w 


"r 


h" 


q 


a 


e 


g 


j 


o 


p 




w 


"r 


i" 


z 


c 


e 


g 




n 


p 




w 


"r 


j" 


q 


a 


d 


g 


j 


m 


p 




w 


"r 


k" 


q 


a 


e 






m 


s 




y 


"r 


1" 


q 


a 


d 


\ 


j 


o 


p 




y 


"r 


m" 


q 


a 


e 






m 


s 




w 


"r 


n" 


q 


a 


e 






0 


s 




w 


"r 


o" 


q 


b 


d 


g 




m 


p 


u 


w 


"r 


P" 


q 


a 


d 


g 




0 


r 




w 


"r 


q" 


q 


a 


d 


g 




m 


P 




w 


"r 


r" 


q 


a 


e 


i 




o 


P 




y 


"r 


s" 


q 


a 


e 


i 




o 


P 




w 


"r 


t" 


z 


a 


e 


h 




n 


s 


u 


w 


"r 


u" 


q 


c 


e 


g 




n 


s 




w 


"r 




q 


a 


e 


i 


j 


m 


p 




w 



FIG. lOM 



93 

ISOOCtD: <EP_0779759A2_L> 



EP 0 779 759 A2 



II 


II 


1 


2 


3 


4 


5 


6 


7 


8 


9 


"r 


w" 


q 


a 


d 


i 


j 


o 


P 


t 


w 


II 


x" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


M „ 


y" 


q 


b 


d 


i 


j 


m 


P 


t 


w 


tl ^ 


z" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


ft 


It 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"s 


a" 


q 


b 


d 


g 


1 


m 


P 




y 


"s 


b" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"s 


c" 


q 


a 


d 


h 


1 


o 


r 


u 


w 


"s 


d" 


q 


a 


d 


g 


j 


n 


P 


t 


w 


"s 


e" 


q 


c 


e 


g 


1 


n 


r 


t 


y 


"s 


f 


q 


a 


e 


g 


j 


m 


P 


u 


w 


"s 


g" 


q 


a 


d 


g 


j 


m 


r 


t 


w 


"s 


h" 


q 


a 


e 


i 


1 


o 


r 


t 


w 


"s 


i" 


z 


c 


d 


g 


1 


n 


s 


t 


X 


"s 


j" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"s 


k" 


q 


a 


e 


i 


j 


m 


P 


t 


w 


"s 


1" 


q 


a 


e 


i 


j 


o 


P 


t 


y 


"s 


m" 


q 


a 


e 


i 


j 


o 


s 


t 


w 


"s 


n" 


q 


a 


e 


g 


j 


m 


p 


t 


w 


"s 


o" 


q 


c 


f 


g 


1 


m 


r 


u 


w 


"s 


P" 


q 


a 


e 


g 


1 


o 


r 


t 


w 


"s 


q" 


q 


a 


d 


g 


1 


m 


P 


u 


w 


"s 


r" 


q 


c 


d 


g 


j 


m 


P 


t 


w 


"s 


s" 


q 


a 


e 


i 


j 


o 


P 


u 


w 


"s 


t" 


q 


a 


e 


i 


i 


o 


r 


u 


y 


"s 


u" 


q 


b 


e 


g 


1 


m 


P 


t 


w 


"s 


V" 


q 


a 


d 


g 


j 


m 


P 


t 


w 


"s 




q 


a 


e 


i 




o 


P 




w 


"s 


x" 


q 


a 


d 


g 




m 


P 




w 


"s 


y" 


q 


a 


d 


g 




m 


s 




w 


"s 


z" 


q 


a 


d 


g 




m 


P 




w 


"s 


tl 


q 


a 


d 


g 




m 


P 




w 


"t 


a" 


q 


c 


f 


i 




n 


r 




y 


"t 


b*- 


q 


a 


d 


g 




m 


P 




w 


"t 


c" 


z 


a 


d 


h 




o 


P 




w 


"t 


d" 


q 


a 


d 


g 




m 


P 




w 


"t 


e" 


q 


c 


d 


g 




m 


r 


u 


X 



FIG. ION 



94 

4SDOCID: <EP_0779758A2_I_> 



EP 0 779 759 A2 







1 


2 


3 


4 


5 


6 


7 


8 


9 


I 


I 




d. 


A 
U 


1 


J 


o 


P 


t 


wr 
W 


I 


g 


Q 


Q 
CL 


C 






r\ 
\J 


P 


t 
I 


VI/ 

W 


I 


n 


4 


d 




1 




c\ 

\J 


r 
1 




w 


I 


i" 
1 


-w 






s 




r\ 
\J 


c 
o 


V 


w 

w 


"t 


J 


n 


a 


H 
\x 


o 

a 


■! 


m 

Ail 


n 


t 




"r 
I 


K 




Q 

d 


C 


g 




m 
111 


n 
F 


L 


w 


I 


I 


Q 


ct 


C 


1 
1 




ill 


P 


f 


\r 
J 


"t 


III 


M 




P 


Q 
& 






n 




w 


"t 


n" 
11 




«l 


w 


g 




m 
1,11 




t 
K 


VT 


I 


n" 
u 








o 
B 




m 


r 
1 


11 


W 

TT 




P 


4 


p 

w 




Q 

B 




m 


n 

F 


u 


w 




n" 
H 


4 


o 

a. 


Li 


g 




111 


P 


t 

X 


w 

w 




-tt 

r 


4 


•1 


C 


i 


. 


r\ 
V/ 


P 


u 


V 
J 




s 






c 


I 


•j 


\J 


P 


U 


VY 


t 


t 


4 


£1 


6 


1 


: 


o 


P 


I 


y 


**«■ 


u 


4 


21 


f 
1 


1 


-! 


11 


f- 

1 


f 
L 


w 


I 


V 


/-I 


a 


u 


g 




111 


P 


t 
1 


w 

w 


t 


W 


q 


H 


e 


1 




O 


P 


t 
i 


w 


t 


X 




£L 


Q 


g 




m 


P 


* 
I 


w 


t 


y 


q 


a 


G 


g 


! 


m 


P 


* 
1 


w 


t 


Z 


q 


a 


0 


g 


J 


m 


P 


4- 
l 


w 


t 




q 


a 


a 


g 


J 


m 


P 


t 


W 


u 


a 


q 


a 


a 


g 


! 


n 


r 


t 


W 


u 


0 


q 


a 


e 


i 


J 


m 


s 


t 


w 


• u 


c 


q 


c 


e 


u 

n 


K 


m 


P 


t 
I 


w 


u 


a 


q 


a 


e 


i 


•! 


o 


P 


t 


y 


u 


e 


q 


a 


a 


g 




n 


s 


t 
I 


w 


u 


f" 


q 


o 
A 


f 
i 


rr 

B 




m 
111 


P 


t 
I 


w 


"u 


g" 


q 


a 


e 


h 




m 


s 


t 


w 


"u 


h" 


q 


a 


d 


g 




m 


P 


t 


w 


"u 


i" 


q 


c 


d 


g 




n 


r 


t 


w 


"u 


j" 


q 


a 


d 


g 




m 


P 


t 


w 


"U 


k" 


q 


a 


d 


g 




m 


P 


t 


w 


"u 


r 


q 


a 


d 


g 




m 


P 


t 


y 


"u 




q 


b 


e 


i 




m 


P 


t 


w 


"u 


n" 


q 


c 


d 


i 




n 


s 


t 


w 


"u 


0" 


q 


a 


d 


g 


j 


m 


P 


t 


w 



FIG. 100 



95 

^SDOCID: <EP_0779759A2_I_> 



EP 0 779 759 A2 







1 


2 


3 


4 


c 

D 


D 


/ 


Q 
O 




"u 

u 


d" 

V 


n 


a 

*x 


d 


i 


1 


o 


n 




V 


u 


n" 
H 


n 
M 


a 
a 


H 
u 


o 
B 


i 
J 


m 
til 


n 




TV 


u 


r" 
I 


r\ 

4 






1 


1 


n 


c 




y 


U 


S 




o 
a 


c 


1 


1 
1 


fin 
lii 


c 




y 




t" 
I 


4 


o 

a 


p 

c 


1 
1 


1 
I 




c 




w 


U 


u 


q 


C 


A 
Q 


ct 
g 


J 


m 
III 


P 




w 


u 


V 


Q 


a 


A 
U 


cr 
B 


J 


m 
111 


ri 
P 




w 


"ll 

u 


w" 

w 


4 


o 

a 


H 
U 


CT 

B 


J 


m 
111 


P 




w 


"ll 

u 


v" 
A 


4 




A 
\X 


rw 

B 


J 


111 


P 




w 


'•ll 
11 


y 


4 




6 


g 


J 


111 


c 




VI/ 

w 


"ll 

u 


t" 

z 




o 

a 


U 


cr 

g 




m 
III 


P 




w 


"■1 

u 


tl 


q 


a. 


U 


g 




III 


P 




vV 


V 


a 


q 


c 




1 




U 


r 




w 


V 


D 


q 


H 


A 

U 


g 




III 


P 




w 


V 


c 


q 


a 


A 
G 


g 




m 


s 




w 


V 


H" 


q 


a 


A 
Q 


g 




111 


P 




w 


V 


#»" 


q 


o 
d 


A 
KX 


g 




11 


i 




w 


V 


1 


q 


a 


A 

a 


8 




m 


P 




11/ 

w 


"v 
V 


rr" 


4 


o 
a 


A 

u 


g 




111 


P 




w 


"v 
V 


h" 


4 


d. 


A 
KX 


g 




m 
III 


V 




w 
w 


"v 

V 


1 


4 






cr 
B 




n 


c 




Vt 


V 


J 


4 


d 


A 
\X 


n 

B 




tn 
111 


P 




w 
w 


"v 

V 


Iw 


4 


d 


H 


B 




m 


F 




w 


V 


I" 
i 


4 


Q 




cr 

B 




m 


c 




w 

TV 


"v 


111 


4 


a 

u. 




Q 

B 




rn 


n 
F 




w 


V 


n" 


ri 

q 


o 
cl 


d 


a 
B 




m 

AAA 


n 

F 




w 


"v 


n" 
u 


q 


a 
a 


d 


i 






r 

M. 




w 

TT 


"v 


n" 




a 


d 


o 




m 


F 




w 


"V 


q" 


q 


a 


d 


g 




m 


p 




w 


"V 


r" 


q 


a 


d 


g 




m 


p 




w 


"V 


s" 


q 


a 


d 


g 




m 


p 




w 


"V 


t" 


q 


a 


d 


g 




m 


p 




w 


"V 


u" 


q 


a 


d 


g 




m 


p 




W 


"v 


v" 


q 


a 


d 


g 




m 


p 




W 


"V 


w" 


q 


a 


d 


g 




m 


p 




W 


"V 


X" 


q 


a 


d 


g 




m 


p 




W 


"v 


y" 


q 


a 


d 


g 


j 


m 


p 




W 



FIG. lOP 



96 

4SOOCID: <EP_0779759A2_L> 



EP 0 779 759 A2 







1 


2 


3 


4 


5 


6 


7 


8 


9 


V 


— " 

z 


q 


a 


d 


g 


J 


m 


P 




w 


V 


II 


4 


d 


u 


g 


j 


m 


P 




w 


w 


a" 

a 


H 


h 




1 


1 
1 


11 


r 


V 


y 


w 




4 


d 




o 

B 




m 

Jit 


P 




w 


"w 

w 


c" 


4 


u 




Q 
& 


\ 


111 


r\ 

F 




w 


w 


d" 


4 


•1 
cl 


f 
i 


o 
6 




lit 


P 




w 


w 


e" 


n 

4 


u 




1 




n 
11 


r 


V 


w 


"w 


r 


n 
4 




d 


g 
& 




m 


n 




TV 


w 




4 


d. 




ff 
B 




m 
111 


P 




w 


"w 


h" 


o 
4 


;) 




1 
1 




KJ 


n 

P 




y 


"w 


i" 


n 
4 




d 


g 


j 


n 


c 




w 
w 


"w 


J 


n 
4 


a 


d 


g 




m 


n 
P 




w 


"w 


k" 

IV 


n 
4 


a 


d 


g 
6 




m 

Hi 


P 




w 


"w 
w 


1" 

1 


4 


u. 


d 


CT 

B 




111 


P 




w 


w 


m" 
111 


4 


o 
<X 


d 


ft 
B 




m 
- Ill 


P 




w 


w 


11 


4 


o 


d 


ry 

B 




III 


c 




w 


w 


\j 


4 


o 
(t 


d 


s 


. 

\ 


11 


1 


U 


11/ 

w 


W 


P 


4 


a 


Cl 


n 


\ 


m 


P 




w 


W 


Q 


/I 


a 


U 


g 


\ 


m 


p 




w 


W 


n 

r 


q 


E 


a 


i 


\ 


o 


P 




w 


W 


s 




cl 


c 


g 


\ 


m 


p 




W 


w 


t 


q 


a 


a 


g 


J 


m 


P 




W 


w 


u 


q 


a 


a 


g 


J 


m 


p 




w 


W 


V 


q 


E 


G 


g 


J 


m 


p 




w 


w 


w 


4 


d 


H 
u 


g 


\ 


m 


p 




w 


W 


A 


q 


d 


u 


g 


\ 


m 


p 




w 


"w 


y 


Cl 
M 




d 


a 
B 




m 
ill 


p 






"w 


z" 


q 


a 


d 


g 




m 


p 




w 


"w 


tl 


q 


a 


d 


g 




m 


p 




w 


"x 


a" 


q 


c 


d 


g 




m 


p 




w 


"X 


b" 


q 


a 


d 


g 




m 


p 




w 


"X 


c" 


q 


a 


e 


h 




m 


P 




w 


"X 


d" 


q 


a 


d 


g 




m 


P 




w 


"X 


e" 


q 


c 


d 


g 




m 


s 




X 


"X 


f 


q 


a 


d 


g 




m 


P 




w 


"x 


g" 


q 


a 


d 


g 




m 


P 




w 


"X 




q 


a 


d 


g 




m 


P 




w 



FIG. lOQ 



97 

4SDCCID: <EP__0779759A2J_> 



EP 0 779 759 A2 



t1 




1 

1 






4 




6 


7 


g 


9 


"x 


i" 


q 


c 


d 


g 


j 


n 


s 


t 


w 


"X 


j" 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"X 


k" 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"x 


1" 


q 


a 


d 


i 


j 


m 


p 


t 


w 


"X 


m" 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"X 


n" 


q 


a 


d 


g 


j 


m 


p 


t 


w 


"x 


o" 


q 


a 


d 


g 


j 


m 


P 




w 


"x 


p" 

tr 


q 


a 


e 


i 




o 


P 




w 


"x 


q" 


Q 


a 


d 


g 


j 


m 


P 




w 


"x 


r" 


O 
M 


a 


d 


s 

o 


j 


m 


P 
* 




w 


"x 


s" 


Q 


a 


e 


i 


j 


m 


P 




w 


"x 


t" 


a 


a 


e 


E 


j 


m 


r 




w 


"x 


u" 


Q 


a 


d 


g 


j 


m 


p 




w 


"x 


v" 


a 


a 


d 


2 


j 


m 


P 




w 


"x 


w" 


a 


a 


d 


e 


j 


m 


P 

tr 




w 


"x 


x" 


Q 


a 


d 


g 


j 


tn 


P 




w 


"x 


v" 


z 


a 


d 


e 


j 


m 


P 

IT 




w 


"x 


z" 


n 


a 


d 


fi 


j 


m 


P 




w 


"x 




n 

M 


a 


d 


fi 


j 


m 


P 


( 


w 


"y 


a" 


q 


a 


d 


g 


j 


m 


P 




w 


"y 

J 


b" 


q 


a 


e 


i 


j 


o 


P 




w 


"v 


c" 


q 


a 


d 


g 




0 


P 




w 


"y 


d" 


q 


a 


d 


g 


j 


m 


P 




w 


"y 


e" 


q 


a 


e 


g 


j 


m 


s 




w 


"y 


r 


q 


a 


d 


g 


j 


m 


p 




w 


"y 


g" 


q 


a 


d 


g 


j 


m 


p 




w 


"y 


h" 


q 


a 


d 


g 


j 


o 


p 




w 


"y 


i" 


q 


c 


d 


g 




n 


P 




w 


"y 


j" 


q 


a 


d 


g 




m 


P 




w 


"y 


k" 


q 


a 


d 


g 




m 


P 




w 


"y 


1" 


q 


a 


e 


g 




m 


P 




w 


"y 


m" 


q 


a 


e 


g 




0 


P 




w 


"y 


n" 


q 


c 


d 


g 




m 


P 




X 


"y 


o" 


q 


a 


d 


g 




n 


r 


u 




"y 


P" 


q 


a 


e 


i 




m 


P 




w 


"y 


q" 


q 


a 


d 


g 




m 


P 




w 


"y 


r" 


q 


a 


d 


i 




m 


P 




w 



FIG. lOR 



98 

JSOOCfCh <EP 0779759A2_I_> 



EP 0 779 759 A2 



II 




1 

J. 


2 


3 


4 


5 


6 


7 


8 


9 


"y 


s" 


q 


c 


e 


i 


j 


m 


P 


t 


w 


"y 


t" 


q 


a 


e 


h 


j 


m 


p 


t 


w 


"y 


u" 


q 


a 


d 


g 




m 


r 


t 


w 


"y 


v" 


q 


a 


d 


g 




m 


p 


t 


w 


"y 


w" 


q 


a 


d 


h 




m 


p 


t 


w 


"y 


x" 


q 


a 


d 


g 




m 


p 


t 


w 


"y 


y" 


q 
* 


a 


d 


g 




m 


p 


t 


w 


"y 


z" 


q 


a 


e 


g 




m 


p 


t 


w 


"y 


tl 


q 


a 


d 


g 




m 


p 


t 


w 


"z 


a" 


q 


a 


d 


g 




m 


P 


t 


w 


"z 


b" 


q 


a 


d 


g 




m 


p 


t 


w 


"z 


c" 


q 


a 


d 


g 




m 


p 


t 


w 


"z 


d" 


q 


a 


d 


g 




m 


p 


t 


w 


"z 


e" 


q 


a 


d 


g 




n 


r 


t 


w 


"z 


r 


q 


a 


d 


g 




m 


P 


t 


w 


"z 


g" 


q 


a 


d 


g 




m 


P 


t 


w 


"z 


h" 


q 


a 


d 


g 




m 


P 


t 


w 


"z 


i" 


q 


a 


d 


g 




n 


P 


t 


w 


"z 


j" 


q 


a 


d 


g 




m 


P 


t 


w 


"z 


k" 


q 


a 


d 


g 




m 


p 


t 


w 


"z 


1" 


q 


a 


d 


g 




m 


p 


t 


w 


"z 


m" 


q 


a 


d 


g 




m 


p 


t 


w 


"z 


n" 


q 


a 


e 


g 




m 


p 


t 


w 


"z 


o" 


q 


a 


d 


g 




n 


p 


t 


w 


"z 


P" 


q 


a 


d 


g 




m 


p 


t 




"z 


q" 


q 


a 


d 


g 




m 


p 


t 


w 


"z 


r" 


q 


a 


d 


g 




m 


p 


t 


w 


"z 


s" 


q 


a 


d 


g 




m 


P 




w 


"z 


t" 


q 


a 


d 


g 




m 


P 




w 


"z 


u" 


q 


a 


d 


g 




m 


P 




w 


"z 


V" 


q 


a 


d 


g 




m 


P 




w 


"z 


w" 


q 


a 


d 


g 




m 


P 




w 


"z 


X" 


q 


a 


d 


g 




m 


P 




w 


"z 


y" 


q 


a 


d 


g 




m 


P 




w 


"z 


z" 


q 


a 


d 


g 




m 


P 




w 


"z 


ft 


q 


a 


d 


g 




m 


P 




w 


n 


a" 


q 


c 


d 


i 




n 


r 




w 



99 

4S0CC1D: <EP_0779759A2_L> 



EP0 779 759A2 



tt 


If 


1 


2 


3 


4 


5 


6 


7 


8 


9 


tl 


h" 


H 


Q 

a. 


c 






r\ 
U 




u 


y 


M 


c" 


4 


a 




h 




yj 


r 
1 


11 


y 


It 


d" 


n 
M 


a 








KJ 


r 
1 


U 


W 


tl 


e" 


n 
4 




d 






n 


c 
o 


V 

T 




It 


r 


Q 


a 


e 






o 


r 


u 


W 


II 


b" 


4 


a 










r 


II 


w 


It 


h" 


q 


a 


e 


j 


j 


o 


D 

tr 


t 


W 


It 


i" 


4 




f 


p 
a 


j 






t 


w 


tl 


i" 

J 


0 


a 




g 




o 


D 
F 




W 


11 


k" 


q 


b 


e 




j 


n 


n 
r 


t 


w 


It 


r 


n 

M 


a 


e 




1 


0 




u 

vl 


V 

J 


It 


m" 


q 


a 


e 


J 


k 


0 


s 


u 


V 
J 


II 


n" 


Q 


a 


e 


J 


i 


o 


n 
F 




w 


tl 


o" 


z 


b 


f 


a 


k 


n 


r 
1 


11 


w 


It 


d" 


4 


a 




h 


1 




r 
1 


II 
u 


w 


tl 


q" 


Z 


a 


d 


g 




m 


P 


u 


w 


tt 


r" 


q 


a 


e 


i 




o 


s 


u 


w 


It 


s" 


q 


c 


e 


h 




o 


P 


t 


y 


tt 


t" 


q 


a 


e 


h 




o 


r 


u 


w 


n 


u" 


q 


a 


d 




k 


n 


s 


t 


w 


It 


V" 


q 


a 


e 




1 


o 


P 


t 


w 


It 


w" 


q 


a 


e 






0 


r 


t 


w 


tl 


X" 


q 


a 


d 


g 




m 


P 


t 


y 


tl 


y" 


q 


a 


e 






o 


P 


u 


w 


tt 


z" 


q 


a 


e 






o 


P 


t 


y 


tl 


tl 


q 


a 


f 




1 


0 


s 


t 


w 



FIG. lOT 



100 

4SDCX:iD: <EP_0779759A2_I_> 



EP0 779 759 A2 




JSDCXID: <EP_0779759A2_L> 



101 



EP 0 779 759 A2 





(12) 



(88) Date of publication 

17.11.1999 Bulletin 1999/46 

(43) Date of publication A2: 

ia06.1997 Bulletin 1997/25 

(21 ) Application number: 96309006.3 

(22) Date of filing: 11.12.1996 



EuropSisches Patentannt 
European Patent Office 
Office europ^endes brevets (11) EP 0 779 759 A3 

EUROPEAN PATENT APPLICATION 

(51) intCl.^: H04Q7/24, H04L 12/28 



(84) 


Designated Contracting States: 


(72) 


Inventor: Rossmann, Alain 




AT BE OH DE DK ES R FR GB GR IE IT Li LU MC 




Palo Alto, CA 94303 (US) 




NL PT SE 










(74) 


Representative: 


(30) 


Priority: 1 1 .1 2.1995 US 57021 0 




Freeman, Jacqueline Carol 




11.12.1995 US 570384 




W.P. THOMPSON & CO. 








Celcon House 


(71) 


Applicant: Unwired Planet, inc. 




289-293 High Holbom 




Redwood City, CA 94065 (US) 




London WC1 V 7HU (GB) 



(54) A method and architecture for an interactive two-way data communication network 

(57) A two-way data communication device such as 
a data ready cellular telephone, a two-way pager, or a 
telephone communicates via a two-way data communi- 
cation network with a server compute on a computer 
network that has an interface to the two-way data com- 
munication networK i e, is coupled to the two-way data 
communication network. For example, the computer 
network can be a corporate wide area network, a corpo- 
rate local area network, the Internet, or any combination 
of computer networks. The two-way data communica- 
tion device utilizes a client module to transmit message 
including a resource selector chosen by the user to a 
server on a server computer on the computer network. 
The server processes the message and transmits a 
response over the two-way data communication net- 
work to the client module. The client module interprets 
the response and pr^ents the response to the user via 
a structured user interface. Alternatively, the user trans- 
mits a request that directs the server to transmit tiie 
response to the request to another location or to 
another user. 



CO 
< 

LO 

1^ 
o 

LU 



Primed by Xerox (UK) Busine&s Services 
2,16.7/3.6 



SDOCID: <EP__0779759A3_1_> 



EP 0 779 759 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



AppllcatfcMi Number 

EP 96 30 9006 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation ol document witti Indication, wtiais appropriale, 
of relevant passages 



Relevant 
to claim 



CUkSSFICATION OF THE 
APPLICATION (lnt.CL6) 



X 
A 



LILJEBERG M ET AL: "OPTIMIZING WORLD-WIDE 
WEB FOR WEAKLY CONNECTED MOBILE 
WORKSTATIONS: AN INDIRECT APPROACH" 
INTERNATIONAL WORKSHOP ON SERVICES IN 
DISTRIBUTED AND NETWORKED ENVIRONMENTS, 
5 June 1995 (1995-06-05), pages 132-139, 
XP000764774 

* the whole document * 

KAASHOEK M F ET AL: "DYNAMIC DOCUMENTS: 
MOBILE WIRELESS ACCESS TO THE WWW" 
PROCEEDINGS, WORKSHOP ON MOBILE COMPUTING 
SYSTEMS AND APPLICATIONS, 
8 December 1994 (1994-12-08), pages 
179-184, XP002016896 

* the whole document * 

WO 93 16550 A (BELL ATLANTIC NETWORK 
SERVICES) 19 August 1993 (1993-08-19) 

* page 10, line 15 - line 22 * 

* page 11, line 19 - page 12. line 2 * 

* page 17, line 6 - page 18, line 14; 
figures 6,7 * 

GESSLER S ET AL: "PDAs as mobile WWW 
browsers" 

COMPUTER NETWORKS AND ISDN SYSTEMS, 
vol. 28, no. 1, 

1 December 1995 (1995-12-01), page 53-59 
XP004001210 
ISSN: 0169-7552 

* the whole document * 

-/-- 



1-11. 
25-29 



H04Q7/24 
H04L12/28 



1-11. 
23-29 



36 
1,2 

36-39 



TECHNICAL RELOS 
SEARCHED (tnt.CI.6) 



H04Q 

H04L 
G06F 



The present search report has t>een drawn up (or all daims 



THE HAGUE 



OaM ol eompMfon of tM Mwcn 

23 September 1999 



Gerllng, J.C.J. 



CATCGORY OF CITED OOCUMEMTS 

X ; panicularly relevant taken alone 

Y : particularly r^vant iS combined wlh another 

document of the samo category 
A : technolo^cal background 
O : mn-written disclosure 
P : irtermediatd document 



T : theory or princpte uruterlylng the trrvention 
E : eaiHer patont document. toiA piDf shed on, or 

after the fKing date 
O : docurner^ cited in the apptication 
L : document cKed (or other reasons 



& : iremtser of the same patent family, corresponding 
document 



2 



JSOOCID: <EP__0779759A3J_> 



